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ABSTBACT 


The  Naval  Facilities  Engineering  Command  utilizes 
several  automated  systems  in  carrying  out  its  mission.  These 
systems  are  presently  geared  toward  the  Headquarters  and 
major  Command  levels  cf  management  and  not  toward  the  field 
activities  and  smaller  offices.  This  thesis  examines  an 
Architect-Engineer  type  contracting  management  procedure  and 
proposes  an  automated  alternative  of  the  contract  adminis¬ 
tration  process  using  micro-computer  technology  for  field 
activities.  A  brief  examination  is  made  of  the  NAVFAC  auto¬ 
mated  systems  and  of  the  structure  of  the  NAVFAC  contracting 
organization  prior  to  the  presentation  of  a  proposed  A-E 
Management  Information  System.  The  closing  chapters  discuss 
integration  of  the  proposed  system,  automated  tools  which 
make  the  system  possible  and  the  interface  designs  utilized 
to  make  the  system  user  friendly.  t ^  • 
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I.  INTRODUCTION 


A.  OVERVIEW 

The  Naval  Facilities  Engineering  Command  has  the  mission 
within  the  Navy  of  the  plant  management  of  naval  shore 
facilities.  The  support  structure  for  the  organization  is 
comprised  of  upper  level  program  managers,  geographically 
located  design  divisicns,  intermediate  contracting  offices 
and  activity  level  monitoring  staffs.  One  major  management 
function  of  NAVFAC  contracting  is  for  Architect-Engineering 
services,  maintenance  services  and  construction.  This  func¬ 
tion,  as  well  as  the  other  NAVFAC  functions,  is  supported 
through  an  automated  management  system  which  has  grown  from 
a  mechanized  accounting  system  in  the  late  1940's  to  a 
guasi-distributed  automated  system.  To  a  limited  extent,  the 
functional  distribution  of  the  system  has  reached  some 
Engineering  Field  Divisions  and  is  beginning  to  reach  sene 
field  activities.  This  thesis  will  explore  the  possiblity 
of  automating  the  field  activity  functions  concerned  with 
the  Architect- Engineering  contract  process. 

The  following  is  an  overview  of  the  thesis  chapters: 

Chapter  II.  -  Naval  Facilities  Engineering  Command 

The  overall  mission  of  the  command  and  in  particular 
the  contracting  aspect  are  discussed. 

Chapter  III.  -  Naval  Facilities  System  (NFS) 

The  automated  management  system  is  discussed.  The 
major  components  which  constitute  the  NAVFAC  informa¬ 
tion  system  are  described  along  with  a  discussion  ot 
the  advantages  and  benefits  of  evolving  from  a  file 
oriented  structure  to  a  generalized  Data  Ease 
Management  System.  The  Naval  Facilities  Systems 


Office  is  described  and  its  changing  role  in  the  NFS 
is  discussed. 

Chapter  IV.  -  The  A-E  Contracting  Process 

A  brief  description  os  given  of  the  steps  required  by 
the  contract  administration  staff  to  put  an  A-E 
contract  through  the  three  phases  of  the  A-I 
contracting  life-cycle,  pre-negotiation,  negotiation, 
and  post-award  phases. 

Chapter  V.  -  Requirements  Determination 

The  automated  support  needed  by  the  field  activities 
to  adequately  use  the  data  collected  for  the  NFS  is 
identified.  Tools  are  described  which  could  be  used 
to  build  a  proposed  management  information  system  for 
the  A-E  contracting  environment. 

Chapter  VI.  -  Automation  of  the  Pre-Negotiation  Phase 
Discussion  of  a  proposed  management  information 

system  for  the  A-E  contract  administration  process 
begins  in  this  chapter  and  concludes  in  chapter  8. 
The  Pre-Negotiation  steps  are  discussed  in  the  auto¬ 
mated  environment.  Means  and  methods  of  automating 
the  process  are  investigated.  The  major  concepts 
involved  are  the  use  of  databases,  report/letter 
files  and  application  modules  to  drive  the  entire 
contracting  administration  process. 

Chapter  VII .  -  Automation  of  the  Negotiation  Phase 

A  similar  approach  is  taken  as  described  in 
Chapter  6. 

Chapter  VIII .  -  Automation  of  the  Post-Award  Phase 

A  similar  approach  is  taken  as  described  in 
Chapter  6. 

Chapter  IX.  -  End-Oser  Interface 

Considerations  of  the  users  of  the  automated  systems 
in  terms  of  the  best  interface  design  are  discussed. 
Also  discussed  are  the  factors  that  affect  the 


end-user’s  perception  of  the  system  and  various 
screen  design  methodologies.  Samples  of  recommended 
screen  designs  are  presented. 

Chapter  X.  -  System  Integration 

An  overall  view  of  the  proposed  automated  A-E 
contracting  system  is  presented  along  with  a  review 
of  the  automated  tools  which  comprise  the  subsystems 
of  the  MIS  for  the  A-E  process.  The  chapter  concludes 
with  a  discussion  of  how  the  field  office  could  best 
utilize  an  automated  system  to  meet  NFS  reguirements 
as  well  as  satisfy  local  management  needs. 

Chapter  XI.  -  Conclusions  and  Recommendations 

General  conclusions  and  recommendations  for 
implementation  of  the  system  in  the  field  are 
discussed. 

E.  GCALS  AHD  OBJECTIVES 

The  objectives  of  this  thesis  are  threefold.  The  author 
focuses  cn  the  management  process  of  the  NAVFAC  Contracting 
Organization  and  how  this  process  affects  the  field  Public 
Works  Officer,  the  Officer  In  Charge  of  Construction,  and 
the  Resident  Officer  In  Charge  of  Construction.  This  will 
satisfj  the  objective  of  the  author  to  become  acguainted 
with  the  Navy  Facilities  System  Plan  [Ref.  1].  Second,  a 
sample  module  of  a  proposed  automated  tracking  and  reporting 
management  system  fcr  A-E  contract"  g  is  presented  through 
the  application  of  a  database  management  system.  This 
permits  the  investigation  of  the  possible  uses  of  a  micro¬ 
computer  database  management  system  in  a  field,  non¬ 
programming,  professional  environment.  The  third  objective 
is  tc  investigate  the  possibility  of  developing  a 
user-friendly  interface  between  a  complex  micro-computer 


database  system  and  the  novice  user.  If  such  a  interface  is 
possible,  the  application  of  micro-computer  based  database 
management  systems  can  be  expanded. 


II.  MlhL  FACILITIES  ENGINEEBING  COMMAND 
A.  NAVFAC  CONTB ACTING 

The  Naval  Facilities  Engineering  Command  (NAVFACENGCCM) 
is  responsible  for  and  authorized  to  perform  the  design, 
planning,  development,  procurement,  construction,  altera¬ 
tion,  repair  and  maintenance  at  all  shore  activities  cf  the 
Naval  Estatlishment  for  public  works  and  public  utilities 
[Bef.  2:  p.1.3.1].  This  responsibility  is  assigned  by  the 

Secretary  of  the  Navy  through  the  Chief  of  Naval  Materiel. 

The  specific  functions  performed  under  this  authority 
are  as  fellows: 

a.  Approving  the  selection  and  compensation  of  an 
architect  or  engineer; 

b.  Approving  the  selection  and  fee  of  a  general  building 
contractor; 

c.  Consent  to  the  placement  of  any  subcontract  fer  civil 
werks; 

d.  Approving  any  plans  or  specifications; 

e.  Approting  of  major  alterations  or  increased  costs 
within  the  estimated  cost  set  forth  in  a  contract  for 
civil  works; 

f.  Inspection,  supervision,  and  administration  cf  the 
terms  of  subcontract  and  acceptance  of  performance; 

g.  Monitoring  compliance  with  labor  standards 
reguirements; 

h.  Ordering  or  approving  changes  relating  tc  civil 
werks; 

i.  Cognizance  of  all  matters  relating  to  the  acquisition 
of  real  property.  [Bef.  3] 
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In  essence,  NAVFAC  is  responsible  for  any  construction 
related  activities  from  cradle  to  grave  throughout  the  Naval 
Shore  Establishment.  This  thesis  will  primarily  focus  on 
the  first  function  mentioned  above,  Architect-Engineering 
contracts.  These  contracting  services  are  utilized  by  the 
NAVFAC  organization  to  augment  in-house  planning  and  design 
capability.  Architect-Engineering  contracts  (hereafter 
referred  to  as  A-E  contracts)  are  used  primarily  to  procure 
design  drawings  and  specifications  for  contemplated 
construction  or  maintenance  and  repair  projects.  A-E 
contracts  can  also  be  utilized  as  a  means:  1)  to  providing 
consultation  to  contract  administrators  during  construction 
projects;  2)  to  incorporate  specialized  review  and  checking 
of  accuracy  of  contractor’s  drawing,  material  lists,  or 
equipment  performance  data;  3)  to  prepare  record  drawings  or 
update  master  drawings  and  plans;  and  4)  to  acquire  inspec¬ 
tion  services  for  construction  work  in  instances  where 
in-house  expertise  is  non-existent  or  not  available. 

B.  NAVFAC  CONTRACTING  ORGANIZATION 

The  sole  "Contracting  Officer"  within  NAVFAC  is  the 
Commander,  NAVFACENGCCM .  All  ether  persons  exercising  NAVFAC 
contracting  authority  act  and  sign  in  the  stead  of  the 
Commander.  The  NAVFAC  Contract  Organization  is  shown  below 
in  Figure  2.1. 

The  primary  players  in  the  contracting  chain  are  the 
Commander  NAVFAC,  Engineering  Field  Divisions  (EFD) , 
Of ficers-In-Charge-cf-Construction  (OICC) ,  and  the  Resident 
Cf f icers-In-Char ge- cf-Constr uction.  As  can  be  seen  in 
Figure  2.1,  the  Comaander  NAVFAC  sits  at  the  head  of  the 
organization  where  all  final  contracting  decisions  reside. 


♦ - > 
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♦ - - + 

I 
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♦ - ♦ 
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Figure  2.1  NAVFAC  Contract  Organization. 


1.  Engineering  Field  Divisions 

The  EFDs  are  organizationally  patterned  after 
Headguarters,  NAVFAC.  A  major  department  of  the  EFD  is  the 
Acquisition  Department.  Four  divisions  under  the  supervision 
of  the  Acquisition  Department  Director  concern  themselves 
with  the  acquisiticr  process:  1)  Acquisition  Project 
Management  Division;  2)  Contract  Division;  3)  Design 
Division;  and  the  4)  Construction  Division. 


a. 


I 


Acquisition  Division 


The  Acquisition  Project  Management  Division 
performs  many  general  acquisition  management  functions.  Its 
major  mission  is  to  monitor  and  coordinate  the  execution  of 
construction  contracts.  In  this  role,  the  EFD  serves  activ¬ 
ities  which  are  located  in  a  NAVFAC  designated  geographical 
area.  responsibility.  To  meet  this  program  management  func¬ 
tion,  the  EFD  develops  listings  of  prospective  A-2 
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contractors/  makes  selections  of  contractors  for  specific 
design  contracts  and  negotiates  contract  fees.  Once 
contracts  are  awarded,  the  staff  coordinates  and  reviews 
contract  design  and  construction  matters.  Any  proposed 
changes  in  the  scope  of  contracts  are  reviewed  ty  this 
office. 

t.  Contract  Division 

The  Contract  Division  is  concerned  with  the 
legal  contractual  matters  and  the  contract  administration 
process.  This  division  provides  the  field  OICC  and  EOICC 
with  interpretations  of  contracts,  policy  guidance  and 
recommendations  on  claims.  Basically,  the  Contract  Division 
acts  as  a  consultant  to  field  contracting  offices  on  more 
difficult  contractual  matters. 

c.  Design  Division 

The  Design  Division  is  a  "government-cvred 
Architect  and  Engineering  organization”  so  to  speak.  It 
performs  the  same  design  functions  that  most  commercial  A-E 
firms  provide.  Approximately  25*  of  the  Design  Division’s 
effort  is  strict  engineering  design  with  the  remaining  15% 
directed  toward  engineering  contracts  management  and 
consulting.  The  Design  Division  reviews  A-E  contracted 
designs  to  ensure  maximum  utilization  of  design  criteria  for 
economical  design  cost  and  quality  construction.  For  field 
activities  they  review  all  field  designs  and  provide 
technical  consultation  on  design  matters. 

d.  Construction  Contract  Management  and 

Administration  Division 

The  Construction  Contract  Management  and 
Administration  Division  manages  construction  executicr  to 
achieve  timely,  quality  construction.  This  division  receives 
support  from  the  three  other  divisions  mentioned  above. 


2 .  Naval  Shore  Activities 

Each  Naval  Shore  Activity  Commanding  Officer  has  on 
his  staff  a  Civil  Engineer  Corps  officer  who  is  responsitle 
for  the  facility  management  of  the  station.  This  officer 
will  he  either  the  Public  Works  Officer  (FWO)  or  a  Staff 
Civil  Engineer  (SCE)  who  in  turn  will  interface  with  the 
station  FWO.  This  officer  and  possibly  his  staff  will 
ensure  the  NAVFAC  mission  is  carried  out  as  described  above. 
The  EFD,  OICC,  and  BOICC  support  the  PWO/SCE.  The  PWC/SCZ 
navigates  projects  through  these  offices  requesting  the 
services  required  tc  properly  manage  the  maintenance, 
repair,  alteration  and  construction  of  local  Naval  Shore 
assets. 

^ •  Officer  In  Charge  of  Construction 

The  OICC  receives  designs  and  contract  specifica¬ 
tions  from  the  EFDs  and  the  PWO  to  be  awarded  as  construc¬ 
tion  contracts.  The  OICC  maintains  lists  of  prospective 
contractors  as  well  as  issues  Bequest  for  Proposals  and 
Invitations  for  Bids.  Contractors  are  screened  by  the  CICC 
staff  to  determine  if  they  qualify  to  bid  on  Navy  construc¬ 
tion  contracts.  This  OICC  office  awards  the  construction 
contracts,  issues  change  orders  to  existing  contracts  and 
approves  performance  payments.  The  official  contract  files 
are  maintained  by  the  OICC. 

4 .  Besident  Officer  In  Charge  of  Construction 

The  BOICC  administers  the  construction  contracts 
awarded  by  the  OICC  cften  physically  located  at  the  EFD.  Ihe 
BOICC  is  also  functionally  responsible  to  the  local  Naval 
Shore  activity  to  ensure  the  contractor  provides  the  best 
guality  construction  permitted  under  the  contract.  The  BOICC 
works  directly  with  the  contractor  in  the  daiiy  execution  of 


the  contracts.  This  interface  includes  inspections  of  work; 
review  cf  material  submittals;  approval  of  payment  requests, 
schedules,  estimates,  shop  drawings,  etc;  and  the  review  and 
surveillance  of  the  contractor’s  Quality  Control  system. 

These  four  organizations,  from  EFDs  down  to  the 


BOICC,  constitute  the  contracting  family  of  NAVFAC.  The 
focus  in  this  thesis  is  on  those  elements  of  the  ECICC  and 
Naval  Shore  Activities  which  are  concerned  with  contracted 
A-E  design  efforts.  These  are  the  organizations  who  would 
benefit  the  most  from  the  micro-compu ter  based  management 
system  proposed  herein. 


III.  B AC KG BOUND 


A.  NAVAI  FACILITIES  SYSTEM 
1 .  System  Overview 

NAVFAC  has  a  single  Automated  Data  Processing  System 
called  the  Naval  Facilities  System  (NFS) .  The  automated  data 
processing  plan  for  the  command  is  published  annually  in  the 
NAVFAC  P-424,  the  Naval  Facilities  System  Plan  [Bef.  1], 
This  plan  provides  the  short  and  long  range  ADP  corporate 
planning  for  NAVFAC.  The  intent  of  the  plan  is  to  optimize 
the  information  technology  currently  available  and  integrate 
existing  management  systems  to  permit  the  managers  of 
programs  to  more  effectively  meet  their  missions.  The  plan 
is  coordinated  with  and  developed  in  conjunction  with  the 
Command  Management  Plan,  the  NAVFAC  command  budget  and  the 
Navy  ADP  budget. 

The  NFS  is  an  accumulation  of  15  interfacing 
Automated  Information  Systems  (AISs) .  These  systems  are 
utilized  in  determining  the  requirements,  making  the  acqui¬ 
sitions  and  monitoring  the  utilization  of  real  property, 
utilities,  and  all  forms  of  civil  engineering  support. 
Figure  3.1  shows  the  relationship  between  the  Fequirements, 
Acquisition,  and  Utilization  of  Real  Property,  Utilities, 
and  Civil  Engineering  Support.  Naval  Force  Planning  deter¬ 
mines  base  loading,  some  required  human  resources  and  the 
mobilization  plans.  The  mobilization  plans  generate  a 
requirement  for  Civil  Engineer  Support  which  further  places 
a  need  for  human  resources  which  in  turn  further  increases 
base  loading.  The  requirements  for  real  property  and 
utilities  are  determined  once  these  needs  are  identified. 
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Acquisition  of  real  property,  utility  systems  and  equipment 
are  budgeted  for  and  then  carried  out.  The  combined  utiliza¬ 
tion  of  the  real  property,  utilities  and  equipment  produce 
the  desired  capability  espoused  by  the  Naval  Force  Planning. 
Four  AISs  are  of  importance  to  this  thesis.  These  AISs  are 
Management  Information  Systems  (MIS)  for  use  by  NAVFAC 
Headquarters,  the  Engineering  Field  Divisions  (EFD) ,  the 
Construction  Battalion  Centers  (CBC) ,  and  the  Public  Works 
Centers  (PWC) .  The  other  11  AISs  are  functional  as 
Navy-wide  applications  in  environmental  protection;  in  shore 
facilities  planning  and  real  estate;  in  military  construc¬ 
tion  programming;  in  support  of  the  Naval  Construction 
Force;  in  construction,  automotive,  and  special  equipment; 
in  base  engineering  support,  energy  conservation,  engi¬ 
neering  research,  family  housing,  base  operating  support; 
and  in  occupational  safety  and  health/deficiency  abatement. 

2 .  Data  Base  Management  System 

The  accumulation  and  management  of  the  data  required 
to  support  the  15  AISs  presents  a  management  challenge. 
Since  the  mid-70's  the  thrust  in  supporting  these  AISs  has 
been  to  adapt  a  generalized  Data  Base  Management  System 
(DBMS)  approach.  Ccrversion  to  a  DBMS  from  a  conventional 
file  oriented  systems  is  a  time  consuming  process.  This 
approach  continues  today  to  replace  the  existing  file 
oriented  system  of  the  NFS  where  a  particular  application 
has  to  have  it's  own  data  file.  A  database  management  system 
is  a  software  tool  that  is  designed  to  manage  and  maintain 
an  organization's  database  resource.  The  DBMS  itself  is  not 
tied  tc  any  particular  set  of  files.  [Bef.  4:  p.333] 

a.  Benefits  of  the  DBMS 

The  conversion  to  a  DBMS  has  many  long  term 
benefits.  Data  captured  in  the  database  becomes  application 
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independent.  The  data  structure  of  the  data  in  the  database 
remains  the  same  no  matter  what,  the  application,  causing 
some  standardization  of  application  development  since  all 
applications  must  access  the  same  structured  data.  However, 
this  does  not  limit  the  applications  since  applications  car. 
build  different  views  of  the  data  simply  by  accessing  and 
merging  the  data  to  suit  the  application  needs.  For  example, 
one  program  could  be  written  to  track  contracts  in  separate 
geographic  areas.  The  program  could  produce  reports  based 
on  just  cne  region  or  it  could  combine  or  extract  data  from 
the  database  to  produce  a  NAVFAC-vide  report. 

Existing  software  is  able  to  provide  logical  as 
well  as  physical  data  independence,  enhancing  the  data 
storage  economies.  Eedundant  data  need  not  be  stored  for 
several  applications.  The  evolution  of  the  database  can 
proceed  without  the  spiralling  cost  of  maintenance  for 
application  programs.  There  no  longer  needs  to  be  updates  to 
application  programs  due  to  data  changes.  With  DBMS  comes 
utility  programs  to  assist  the  Data  Base  Administrators 
(DBA)  to  act  as  controllers  and  custodians  of  the  data  to 
ensure  integrity  of  the  data  and  enforce  the  proper  struc¬ 
ture.  (The  centralized  database  system  currently  in  use 
will  be  discussed  later  in  this  chapter.)  Along  with  integ¬ 
rity  comes  the  requirement  to  protect  the  data  through 
proper  security  measures.  The  data  for  the  most  part  is 
unclassified  administrative  data  for  military  purposes,  yet 
it  is  in  a  sense  administratively  confidential  and  must 
therefore  be  protected.  Access  to  the  database  must  be 
limited  to  those  who  have  a  need  to  know.  The  DBMS  utilities 
will  accommodate  this  requirement  also.  Since  the  DBMS  is 
generalized,  data  migration  across  devices  can  be  facili¬ 
tated  much  easier  as  the  proliferation  of  hardware 
increases.  In  governmental  systems  this  is  important  consid¬ 
ering  the  limitation  of  the  ADP  procurement  policies. 


Managers  of  systems  can  not  always  predict  the  brand  of 
hardware  a  particular  procurement  action  will  produce. 
Another  consideration  is  that  of  an  evolving  functional 
distribution  system.  As  the  system  grows  horizontally  or 
vertically,  the  new  nodes  that  are  placed  on  the  system  may 
or  may  not  be  compatible  with  existing  system  hardware. 
Existing  equipment  must  be  either  directly  compatible  or 
must  be  able  to  interface  through  various  protocols. 

A  current  goal  of  the  NFS  is  the  development  of 
a  complete  data  dictionary  to  cover  all  the  AIS.  This  is 
imperative  for  the  proper  control  of  the  data  validity.  The 
data  dictionary  standardizes  the  data  formats  and  the  actual 
meaning  cf  the  data  elements  for  all  command  systems.  This 
is  not  new  to  the  AIS  but  simply  a  feature  to  have  a  fully 
functioning  DBMS.  The  DBMS  also  permits  various  levels  of 
access  to  the  database.  The  DBA  is  be  able  to  define  the 
structure  of  the  database  through  the  use  of  the  data  defi¬ 
nition  language  (DDL) .  The  DDL  includes  terms  for  defining 
records,  fields,  keys,  and  relationships.  It  also  provides 
facilities  for  expressing  a  variety  of  user  views  and  allows 
the  imposition  of  user  constraints  such  as  editing  capa¬ 
bility,  interrecord  and  intrarecord  browsing.  Access  to  the 
database  by  application  programmers  is  through  the  use  of 
the  database  command  language.  Applications  can  be  written 
for  novice  users  of  the  system  at  EFDs  and  field  activities 
such  that  the  details  of  accessing  the  database  are 
completely  transparent.  For  more  sophisticated  users  who 
wish  to  access  the  database  directly,  a  query  language  is 
available.  This  permits  queries  to  be  made  of  the  database 
to  obtain  quick  answers  to  unanticipated  or  one-time 
queries. 
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t.  Advantages  of  a  E B MS 

A  generalized  DBMS  has  many  advantages  over  a 
conventional  file  oriented  structure.  The  DBMS  allows  mere 
information  to  be  pulled  from  the  same  data.  Consider  a 
distributed  system  where  field  RCICC  offices  would  be  able 
to  access  a  large  database.  Several  applications  could  be 
made  from  the  same  source  data.  For  example,  contract  admin¬ 
istration  on  a  series  of  contracts  could  be  used  to  track 
the  current  workload  at  the  RCICC  level.  The  same  data  at 
the  EFE  level  could  be  used  to  review  the  distribution  of 
design  efforts  over  the  EFD’s  geographical  area  of  responsi¬ 


bility.  At  the  NAVFAC  level  the  same  data  could  be  used  by  a 
program  manager  in  the  development  of  budget  estimations  for 
the  upcoming  budget  process.  The  partitioning  of  data  in  a 
conventional  file  system  makes  the  process  of  gathering  data 
for  these  different  applications  difficult.  In  the  conven¬ 
tional  system,  to  avoid  this  difficulty  it  becomes  necessary 
to  maintain  a  file  for  each  application  creating  vast 
amounts  of  data  redundancy.  Thus  the  DBMS  saves  memory 
space,  speeds  processing  and  data  entry,  as  well  as  enhances 
the  data  integrity. 


c.  Disadvantages  of  a  DBMS 


With  any  improved  system  there  also  exist  seme 
disadvantages  and  turning  to  a  generalized  DBMS  from  a 
conventional  file  oriented  system  is  no  exception.  DBMSs  are 
expensive  to  procure  and  implement  requiring  longer  term 
benefits  to  justify  the  initial  cost.  A  generalized  DBMS  can 
require  a  new  series  of  processors.  This  is  important  if 
the  corporate  processing  involves  more  than  just  database 
processing.  A  dedicated  processor  is  often  the  test  invest¬ 
ment  since  it  will  permit  parallel  processing  of  database 
accesses  and  applications.  Highly  trained  personnel  are 
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required  to  maintain  the  DBMS  environment  and  administration 
and  ccntrol  of  the  DBMS  is  more  complex  than  the  file 
oriented  systems.  Administrative  and  operating  cost  can  be 
expected  to  increase.  Considering  the  disadvantages  and 
comparing  them  to  tie  overall  advantages,  the  long  term 
benefits  of  the  DBMS  over  the  conventional  file  oriented 
system  can  easily  justify  any  of  the  mentioned 
disadvantages. 

3 •  Distributing  The  System 

Another  NFS  initiative  which  reflects  the  changing 
philosophy  of  NAVFAC  is  that  of  expanding  the  number  of 
users  of  the  NFS.  This  expansion  is  being  accomplished 
through  decentralization  and  distribution  of  the  NFS. 
Froject  smart  (source  management  of  resources  and  time)  is 
being  implemented  for  use  at  the  EFD/OICC  level.  The  project 
consists  of  installing  minicomputers  at  the  EFDs  and  CICCs 
to  permit  the  implementation  of  local  management  tcols  and 
the  standardization  cf  existing  office  automation  systems. 
The  objectives  of  project  smart  are: 

a)  provide  additional  processing  capability  for  the 

EFD/OICC; 

b)  achieve  system  revision  and  integration  through 

evolution  net  revolution; 

c)  provide  a  user  friendly  interface  to  permit  query 

language  access  to  the  generalized  DBMS; 

d)  develop  local  application's  from  the  initial  instal¬ 

lation. 

Project  smart  is  scheduled  to  be  fully  implemented  in  all 
EFDs  and  NAVFAC  HQ  by  the  end  of  FI87.  [Ref.  1:  p.5-10] 

Another  form  of  distributing  the  NFS  has  been  the 
decision  to  provide  "teleprocessing"  to  the  EFDs.  Hardware 
has  been  connected  from  the  Facilities  System  Office  (FACSO) 
in  Port  Hueneme,  Ca.  to  the  EFDs  and  to  NAVFAC  HQ  through 


the  use  cf  telecommunication  lines.  The  hardware  includes 
terminals  for  input/output  operations,  and  hardcopy 
printers.  The  remote  sites  can  input  data  directly  tc  the 
Bain  computer  at  FACSC  as  well  as  receive  management  reports 
at  local  printers.  This  type  of  distributed  processing  has 
proven  tc  be  more  effective  and  efficient  than  the  totally 
centralized  approach  used  previously.  [Ref.  1:  p.5-1].  The 
benefits  include  reduced  input  time,  a  more  accurate  data 
discipline,  and  improved  delivery  time  for  outputs. 
Reporting  reguirements  have  also  declined  due  to  the  ability 
of  the  user  to  make  cr-line  queries  of  the  database. 

4 .  Automated  Information  Systems 

Of  the  15  AISs,  only  the  EFD/MIS  will  be  focused 
upon  in  the  remainder  of  the  thesis.  The  EFD/MIS  serves  the 
management  reguirements  of  the  EFDs,  large  OICCs  and  NAVFAC 
HQ.  This  distributed  data  processing  (DDP)  configuration  is 
shown  in  figure  3.2  below.  The  major  data  systems  cf  the 
MIS  are: 

(1)  The  "AMALGABAN"  Data  Base  which  supports  the 
following:  . 

(a)  Integrated  Disbursing  and  Accounting  (IDA) 

(b)  Integrated  Program  Management  System  (l?MS) 

(c)  Construction  Management  System  (CMS) 

(2)  Design  Management  Information  System  (DMIS) 

(3)  Graphics  Design  System  (GDS) 

(4)  Contractor  Information  System  (CIS) 

The  EFD/MIS  has  over  200  computer  programs  and  produces 
approxim  itely  200  standard  titled  reports.  [Ref.  5:  p.i] 
The  data  systems  which  are  of  primary  interest  to  the  EOICC 
are  the  CMS,  DMIS  and  the  CIS. 


Figure  3.2  EFD/HIS  DDP  Configuration 


a.  Construction  Management  System  (CMS) 


The  objective  of  the  CMS  is  to  provide  the 
NAVFAC  level  program  managers  with  the  information  required 
to  monitor  and  control  the  design  and  construction  phases  of 
shore  facilities  projects.  The  reports  produced  provide 
Project  Status  (used  ty  EFD/OICC  and  HQ) ,  Execution  Status 
I  (used  by  EFD  and  HQ),  Work  In  Place  (used  by  RCICC, 

EFD/OICC,  and  HQ)  and  various  other  management  reports. 
[Ref.  5:  p.31] 

b.  Design  Management  Information  System  (DKIS) 

The  DMIS  is  utilized  by  HQ  and  EFD/OICC  design 
managers  tc  manage  the  engineering  and  design  phases  of  the 
NAVFAC  mission.  Three  functional  areas  are  directly 
supported:  design  scheduling,  criteria  scheduling,  and  engi¬ 
neering  and  design  maragement. 

(1 )  Design  Scheduling. 

Design  scheduling  involves  design  job 

I  status,  design  scheduling,  personnel  resource  allocation 

(in-house  vs.  contract) ,  job  cost  control,  and  design 
performance  appraisal. 

(2)  Criteria  Scheduling. 

j  This  application  involves  the  design 

schedule,  milestones,  and  funding  information  used  in  sched¬ 
uling  and  coordinating  the  preparation  of  design  criteria. 
The  system  is  used  tc  plan  goals  that  will  be  established  in 
the  Command  Management  Plan  (NAVFAC  P-441),  and  to  document 
the  progress  of  the  design  goals  which  have  already  been 
established. 

(3)  Engineering  and  Design  Management . 

Used  by  EFD/CICC  and  HQ  program  managers, 

this  application  combines  data  from  several  data  files  and 
aggregates  it  to  a  high  level  to  monitor  the  progress  of 
projects  at  the  EFD/CICC  and  HQ  levels. 


c.  Contractor  Information  System  (CIS) 

The  CIS  is  designed:  1)  to  standardize  proce- 

dures  for  maintaining  contractor  information  for  the  A- 2 
slates  and  mailing  lists;  2)  maintaining  history  of  the 
contractors  efforts  for  the  U.S.  Navy;  and  3) providing 
contractor  data  to  the  CMS  and  IDA  systems  [Ref.  6:  p.1]. 

The  CIS  is  utilized  hy  all  levels  of  NAVFAC  management  for 
all  varieties  of  contractor  information.  The  information  for 
the  CIS  is  drawn  from  contractor  submitted  questionnaires 
(A-E  and  Related  Services  SF  254)  and  Bidder's  Mailing  List 
Application  (SF  129)  .  Updates  are  made  periodically  as  more 
information  is  accumulated  on  various  contractors  through 
submittal  cf  follov-cr  SF  254s. 

d.  NFS  Goals  for  the  EFD/MIS 

The  NFSP ,  [fief.  1:  pp.1-12  -  1-21]  outlines 

several  short  and  long  term  goals  for  the  EFD/MIS  which  in 
general  lead  toward  a  distributed  data  processing  system 
where  the  end-user  will  be  able  to  work  directly  from  the 
generalized  database  system  in  a  virtual  mode.  Some  specific 
goals  are: 

*  Implement  automated  procedures  for  reporting 

individual  procurement  actions  (DD  350  reports). 

*  Develop  a  word  p rocessiny/central  processing 

interface  for  the  ROICC. 

*  Convert  AMALGAM AN/C MS  to  DBMS  with  on-line  query 

capabilities. 

*  Implement  Graphics  Design  System  at  the  EFD  and  HQ 

levels. 

*  Convert  the  DMIS  to  D3MS  for  on-line  query 

capabilit ies. 
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B.  F ACUITIES  SISTEHS  OFFICE 

The  Facilities  Systems  Office  (FACSO)  is  the  hat  cf  the 
NAVFAC  data  processing  system.  Located  at  the  Construction 
Eattalicn  Center,  Pert  Hueneme,  Ca.,  FACSO  is  responsible 
for  the  majority  of  the  development  and  operation  of  the 
NFS.  FACSO's  distributed  network  is  shown  in  figure  3.3 
below  . 

FACSC  has  an  IBB  370/165-11  computer  system  with  4 
million  characters  of  main  memory,  22  gigabytes  of  on-line 
storage,  26  tape  drives,  2  high-speed  non-impact  printers, 
and  6  high-speed  impact  printers.  Two  coupled  Interactive 
Data  Ease  Erocessors  (IDBPs)  with  4  million  bytes  of  memory 
each  were  installed  in  1981/82.  The  IDBPs  handle  all  data¬ 
base  applications  and  share  most  of  the  peripheral  equip¬ 
ment,  thus  relieving  the  370/165-11  of  considerable 
workload.  A  COMTEN  3690  Front  End  Processor  handles  the 
majority  pf  the  telecommunications  interface.  The  device  is 
programmable  and  switchable  so  that  a  given  port  can  handle 
different  types  of  input  terminals  and  route  messages  under 
program  control.  Communication  ports  are  assigned 
dynamically  to  accommodate  the  fluctuating  load.  [Ref.  1: 
p.4-1] 
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NFS  Distributed  Network 


C.  1IHITATI0NS  OF  TBE  NAVAL  FACILITIES  SYSTEM 
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The  paragraphs  above  have  briefly  explained  the  NFS  and 
in  particular  the  EFD/MIS.  The  life  of  the  NFS  continues  to 
be  a  dynamic  one  as  are  all  long  term  data  processing 
systems.  The  system  has  shown  all  the  signs  of  growth  as 
described  by  Nolan  [Bef.  7  :  pp. 115-126].  The  system  began 
as  a  central  data  processing  point  where  all  input  was 
either  sent  via  the  postal  services  or  transmitted  electron¬ 
ically  via  message.  The  data  was  required  to  be  key  punched 
on  data  cards  and  submitted  in  a  batch  mode  with  output 
reports  sent  to  the  users  via  the  postal  service.  The  time 
lapse  from  the  time  the  field  activities  submitted  their 
data  to  FAC SO  (via  the  EFD)  to  the  time  the  output  reports 
were  received  could  be  as  long  as  five  months  but  was 
normally  in  the  order  of  at  least  three  months.  This  manage¬ 
ment  system  did  not  meet  the  management  needs  of  the  field 
activities.  Today  however,  the  NFS  provides  the  ZFDs  and 
NAVFAC  HQ  tetter  management  support  due  to  the  advances  in 
telecommunications  and  the  availability  of  distributed 
processing  at  the  EFD  level. 

A  large  majority  of  the  data  for  the  EFD/MIS  comes  from 
the  field  ROICC  offices.  These  offices  accumulate  this  data 
over  a  period  of  a  month,  in  most  cases  manually,  and  submit 
it  to  the  EFD  where  it  is  validated  and  transmitted  directly 
to  FACSC  through  use  of  the  EFD/MIS  DDP  system  (Figure 
3. 2). The  ROICC  office  will  normally  receive  a  management 
report  within  six  weeks.  This  data  is  in  the  most  part 
historical  and  can  net  be  used  to  effectively  manage  a  day 
to  day  operation.  Therefore  the  collection  and  reporting  of 
the  data  is  only  an  overhead  expense  to  the  field  activity. 

Plans  for  the  future  for  the  NFS  call  for  the  field 
activities  to  have  a  virtual  connection  to  FACSO  just  as  the 
EFDs  enjoy  now.  This  will  permit  the  ROICC  to  collect  data 
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electronically  and  in  turn  transmit  probably  via  the  £FD 
processors  to  FACSO.  The  EOICC  will  also  be  able  to  keep 
on-hand  the  data  for  management  of  daily  operations.  These 
advances  are  just  beginning  to  be  seen  for  some  EOICC 
offices.  WANG  Office  Information  System  (OIS)  hardware/ 
software  is  used  to  permit  collection  of  required  data.  Ihe 
data  is  presently  transmitted  to  the  EFD  by  mailing  disks. 
Direct  transmission  to  the  EFDs  is  not  possible  at  the 
present  time.  A  main  concern  of  this  thesis  is  investi¬ 
gating  a  method  by  which  the  field  activities  can  locally 
utilize  the  data  which  is  collected  for  higher  level  manage¬ 
ment.  Currently,  the  majority  of  the  data  remains  to  be 
historical  in  nature.  Systems  can  be  developed  which  will 
incorporate  the  collected  data  into  the  daily  management 
functions  of  the  field  activity.  The  remainder  of  the  chap¬ 
ters  will  be  devoted  to  the  development  of  such  a  system  for 
the  management  of  the  A-E  contracting  process. 


IV.  i;I  CONTRACTING  PROCESS 


A.  GENERAL 

As  mentioned  earlier,  A-E  contracts  are  used  primarily 
to  procure  the  drawings  and  specifications  for  contemplated 
construction  projects  [Eef.  2:  p.2.1.1].  These  contracts 
are  awarded  throughout  the  NAVFAC  contracting  chain.  While 
all  the  contracts  are  awarded  by  following  the  same  required 
contractual  procedures  [Ref.  2],  the  actual  process  will 
differ  from  command  to  command  due  to  differing  management 
styles  of  individual  managers  and  the  local  "traditional 
policies".  The  process  described  below  is  generic  in  the 
•sense  that  all  the  A-E  contracts  go  through  the  same  three 
phases  no  matter  which  command  is  concerned.  There  are  many 
rules  and  regulations  which  govern  the  process  but  it  is  not 
the  intent  of  this  chapter  to  fully  discuss  all  the  legal 
requirements  of  contracting  but  rather  to  focus  primarily  on 
the  process  and  the  accompanying  information  flow  that  the 
manager  must  be  aware  of  in  order  to  manage  the  process. 

Within  the  A-E  type  of  procurement  there  are  several 
different  types  of  contracts.  The  main  difference  in  the 
various  types  is  the  number  of  "actions"  or  "products"  which 
can  be  delivered  under  one  contract.  Some  contracts, 
normally  larger  in  award  amount,  require  the  design  of  cne 
construction  project.  Other  contracts  are  "open-end"  in  that 
a  larger  number  of  designs,  normally  small  in  nature,  can  be 
accomplished  under  one  contracting  vehicle.  Open-end 
contracts  often  are  not  to  exceed  a  predetermined  total 
amount.  These  contracts  are  negotiated  based  on  hourly  fees 
for  particular  technical  skills  rather  than  for  a  total 
design  cost  basis.  Follow-on  work  is  negotiated  based  on 
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the  hours  required  to  accomplish  a  design  task  which  is  then 
translated  into  an  award  fee. 

The  A-E  contracting  process  is  broken  into  three  phases, 
the  pre-negotiation  phase,  the  negotiation  phase  and  the 
post-award  phase.  Each  transition  from  one  phase  tc  another 
is  marked  by  a  distinct  result  or  action.  The  pre¬ 
negotiation  phase  involves  the  initial  request  for  a 
contract  submitted  by  a  customer.  The  phase  ends  when  a 
slate  of  a  few  contractors  is  approved  by  the  selection 
official  for  further  consideration.  The  negotiation  phase 
begins  with  the  selection  of  the  best  qualified  contractor 
from  the  slate  and  concludes  with  the  awarding  of  a  negoti¬ 
ated  contract.  Post-award  is  the  actual  contract  execution 
Fhase.  It  begins  immediately  upon  the  signing  of  a  contract 
and  finishes  when  all  contracted  work  has  been  accepted  by 
the  government  and  final  payment  to  the  contractor  has  been 
made. 

There  are  several  parties  involved  in  the  contracting 
process.  These  include  the  contracting  officer  (CICC, 
EOICC ,  AECICC) ,  the  customer  (organization  whom  the  design 
is  to  benefit),  the  contract  administration  staff,  govern¬ 
ment  engineers  (review  the  contractor's  work  and  accept  it 
as  being  correct),  and  lastly  the  contracted  A-E  firm.  The 
parties  are  involved  to  differing  levels  throughout  the 
contracting  process  as  will  be  seen  in  the  following 
paragraphs. 

B.  P BE- NEGOTIATION  PHASE  (I) 

The  steps  in  the  Pre-Negotiation  Phase  (I)  are  carried 
out  primarily  by  the  contract  administration  staff.  Otter 
key  participants  in  this  phase  are  various  board  members  as 
well  as  the  customer.  The  customer  may  be  someone  in  the 
immediate  contracting  organization  itself  or  maybe  an 


organization  which  is  supported  by  the  contracting  office. 

Figure  4.1  is  a  flowchart  depicting  the  steps  listed  below. 

1.1  Eeguest  for  contract  -  The  contracting  officer  receives 
a  reguest  for  an  A-E  contract.  A  determination  has 
already  been  made  that  the  design  cannot  be  handled  by 
the  in-house  engineering  staff. 

1.2  Contract  Specialist  { CS )  assigned  -  The  contracting 
officer  assigns  a  CS  to  handle  the  contract  reguest. 
This  CS  may  administer  the  contract  from  the  beginning 
of  the  contract  to  the  end  or  the  CS  may  simply  handle 
the  contract  until  the  award  is  made,  depending  on  the 
local  policy. 

1.3  Development  of  Statement  of  Work  (SOW)  -  The  reguesting 
customer  or  the  in-house  engineering  staff  will  develop 
the  SOW  for  the  contract.  The  CS  reviews  the  SOW  for 
completeness  and  correctness.  The  developer  of  the  SOW 
draws  up  the  weighted  criteria  by  which  the  best 
gualified  contractor  can  be  selected. 

1.4  Detailed  Government  Estimate  (GE)  -  In  most  cases  the 
writer  of  the  SOW  also  draws  up  the  GE. 

1.5  F.eguired  Clearances  and  Approvals  -  Depending  on  the 
type  of  funds  used  for  the  design  and  the  type  of 
design,  certain  clearances  and/or  approvals  may  be 
necessary  from  higher  command  levels  before  further 
action  can  be  taken  in  the  contract  process. 

1.6  Small  Business  Set  Aside  Recommendation  -  A 
determination  must  be  made  as  to  whether  the  contract 
will  be  open  to  large  business  or  remain  as  a  small 
business  set  aside. 

1.7  Ccmmerce  Business  Daily  Synopsis  (CBD)  -  The  CS  will 
prepare  the  synopsis  for  the  CBD  and  ensure  that  it  is 
mailed.  The  CBD  announcement  is  a  notice  of  intent  to 
contract. 


Figure  4.1  Pre-Negotiation  Phase  Flowchart 


1.8  Logging  of  SF  254s  and  255s  -  Contractors  responding  to 
the  contracting  announcement  in  the  C3D  are  required  to 
submit  their  firm’s  qualification  on  the  SF  254  (general 
contractor  information)  and  the  SF  255  (contractor 
information  directed  toward  a  particular  announced 
contract  action)  . 

1.9  Board  Appointment  letters  -  The  A-E  contracting  process 
requires  three  contract  boards:  pre-selection  beard, 
selection  board,  and  the  negotiation  and  award  beard. 
Appointment  letters  assigning  the  members  of  the  board 
must  be  sent  out. 

1.10  Pre-selection  -  The  pre-selection  process  is  carried 
out  by  the  pre-selection  board.  All  contractors  submit¬ 
ting  a  SF  255  for  the  contract  are  considered.  The  SF 
255s  are  reviewed  by  the  board  members  and  the  field  of 
qualified  contractors  is  narrowed  to  a  manageable 
number.  The  board  members  are  guided  in  their  selection 
of  the  qualified  contractors  by  the  selection  criteria 
developed  by  the  customer  or  engineering  staff.  The 
slate  of  qualified  contractors  is  approved  by  the 
approving  authority  (based  on  the  amount  of  the 
contract).  The  approval  of  the  pre-selection  board 
report  by  the  proper  authority  is  the  concluding  action 
of  the  pre-negotiation  phase. 

C.  HEGOTIATION  PHASE  (II) 


actual  award  of  the  contract.  The  customei 
role  in  this  phase  with  the  key  players 
selected  contractors,  the  selection  and 
board,  the  selected  contractor  and  the 
depicts  the  negotiation  steps  listed  below. 
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11. 1  Interview  letters  -  Those  contractors  approved  on  the 
Pre-Selection  Board  report  are  sent  letters  to  inform 
them  of  their  pre-selection  and  to  establish  a  time  and 
place  for  an  in-depth  interview  before  the  Selection 
Board. 

11. 2  Interview  of  the  A-E  firms  -  Individual  interviews  are 
conducted  for  each  A-E  contractor.  The  Board  members 
evaluate  the  contractors  against  the  criteria  published 
in  the  CBD  announcement. 

II.  3  Selection  of  a  contractor  -  Based  on  the  interviews, 
the  Selection  board  members  select  a  contractor  who  best 
satisfies  the  selection  criteria.  A  Board  report  is 
prepared  and  signed  by  all  members  of  the  Board.  The 
proper  approving  authority  (depending  on  the  amount  of 
the  contract)  will  either  approve  or  disapprove  the 
selection  of  the  Board. 

11. 4  Bequest  for  Fee  Proposal  -  A  reguest  for  a  fee  proposal 
is  sent  to  the  selected  contractor.  Depending  on  the 
size  of  the  contract,  various  documents  may  also  be 
required  of  the  contractor. 

11. 5  Beceipt  of  the  Fee  Proposal  -  The  fee  proposal  when 
received  is  forward  to  a  lead  engineer  for  review.  The 
engineer  may  or  may  not  be  the  customer.  In  a 
multi-disciplined  contract,  the  proposal  may  be  sent  to 
several  engineers.  The  engineers  may  be  on  the  Selection 
and  Award  Board  as  well.  Here  again,  depending  on  the 
size  of  the  contract,  various  clearances  may  be 
required. 

11. 6  Pre-negotiation  -  The  lead  engineers  in  conjunction 
with  the  CS  will  perform  the  pre-negotiations  with  the 
contractor.  This  can  result  in  revisions  of  both  the 
government  estimate  and  the  contractor  estimate  as  well 
as  clarifications  of  the  SOW.  All  actions  which  take 
place  are  recorded  by  the  CS. 


41 


11. 7  Negotiation  Board  meeting  -  Once  negotiations  with  the 
contractor  are  settled,  the  Negotiation  Board  is  called 
to  meet  in  order  to  review  the  negotiation  proceedings. 
If  the  proceedings  are  agreeable  to  all  the  board 
members,  the  board  report  is  prepared  and  signed  by  all 
the  members  and  is  then  forwarded  to  the  proper  approval 
authority  for  approval. 

11. 8  Negotiation  Beard  Report  Approval  -  The  approving 
authority  reviews  the  Negotiation  Board  report  and 
approves  or  disapproves. 

11. 9  Contract  Award  -  Once  the  approving  authority  approves 
the  Negotiation  Ecard  report  the  contract  can  be  signed 
by  the  proper  authority.  The  signed  contract  is  then 
sent  to  the  contractor  for  signature. 

D.  PCST-AWARD  PHASE  (III) 

The  Post-Award  Phase  carries  the  contract  process 
through  management  and  administration  to  the  final  payment 
and  closing  of  the  contract.  The  normal  players  in  this 
phase  are  the  contractor,  the  lead  engineer  who  will  review 
the  contractor's  drawings,  and  the  CS  who  must  process  the 
payments  for  the  contract.  The  contracting  officer  may  get 
involved  if  problems  arise  in  the  contract.  Figure  4.3 
illustrates  the  steps  of  this  third  phase.  The  contract 
modification  steps  are  not  shown  here  since  the  same  steps 
are  followed  as  in  the  negotiation  phase. 

III.  1  Notification  letters  -  Letters  are  sent  to  all  the 
non-selected  contractors.  These  letters  inform  the 
contractors  of  the  contract  award. 

III. 2  Individual  Procurement  Action  (DD  Form  350)  -  Contract 
actions  exceeding  $10,000  require  the  filing  of  a  DD 
Form  350.  This  form  is  normally  submitted  to  the  EFD. 
The  form  contains  information  pertaining  to  the  awarded 


contract  and  the  procedures  utilized  in  awarding  the 
con  tract. 

111. 3  Other  Reports  -  Depending  on  the  size  of  the  contract, 
it  may  be  necessary  to  notify  NAV  FAC  of  the  award  and 
also  submit  an  award  announcement  to  the  CED. 

111. 4  Distribution  of  Contract  -  Once  all  the  signatures  are 
obtained,  the  contract  can  be  reproduced.  The  contractor 
will  be  sent  several  copies  as  will  the  EFD  and  the 
customer. 

111. 5  Contractor  Meetings  -  Prior  to  the  actual  beginning  of 
the  design  effort,  it  may  be  necessary  to  meet  with  the 
contractor  to  discuss  administrative  matters  or  design 
specifics.  Similar  meetings  may  occur  throughout  the 
life  of  the  contract. 

111. 6  Design  Reviews  -  Design  reviews  are  for  the  purpose  of 
reviewing  the  contractors  work  to  ensure  the  government 
is  obtaining  the  design  as  reguested.  It  also  is  a  key 
feedback  mechanism  to  ensure  customer  satisfaction. 
Design  reviews  occur  normally  when  the  designs  are  at 
the  30%,  60%,  90%  and  final  or  100%  complete  points.  If 
the  design  is  time  critical,  the  60%  review  will 
normally  be  waived.  The  lead  engineer  will  coordinate 
the  reviews  with  the  customers.  The  customers  are  often 
non-technical  and  the  lead  engineer  serves  as  the 
"interpreter".  The  lead  engineer  communicates  to  the  C5 
whether  or  not  the  submittals  meet  the  specifications  of 
the  contract.  The  relationship  between  the  CS  and  the 
lead  engineer  is  of  upmost  importance  in  the  post-award 
p  hase. 

111. 7  Contract  Modifications  -  Contract  modification 
procedures  are  very  similar  to  the  procedures  in  the 
pre-award  phase.  The  procedures  are  as  follows: 

1)  Reguest  for  contract  modification  -  This  would 
normally  be  in  the  form  of  a  request  for 
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additional  work  or  for  a  time  extension  for 
existing  work.  The  customer  will  generate  the 
reguest  for  additional  work  and  the  contractor 
would  request  the  time  extension. 

2)  Changes  Board  appointment  letters  -  Letters  are 

sent  to  Change  Order  3oard  members  notifying  them 
of  the  time,  place  and  circumstances  of  the 
change. 

3)  SOW  revision  -  The  SOW  is  amended  to  reflect  the 

change. 

4)  Preparation  of  the  GE  -  The  GE  is  developed  by  the 

lead  engineer. 

5)  Request  for  Fee  Proposal  -  The  revised  SOW  is 

forwarded  to  the  contractor  with  a  request  for 
the  firm  to  provide  a  fee  proposal. 

6)  Receipt  of  Fee  Proposal  -  The  contractor's  Fee 

Proposal  is  received  by  the  CS  and  forwarded  to 
the  lead  engineer  for  review  and  validation. 

7)  Pre-Negotiation  contact  with  the  contractor  -  The 

contractor  is  contacted  by  the  lead  engineer  and 
the  CS  to  discuss  differences  in  the  contractor's 
estimate  and  the  GZ .  If  required,  any 

clarifications  are  made  and  a  preliminary 
agreement  is  established.  The  GE  or  the 

contractor's  estimate  may  be  adjusted  as 
appropriate. 

9)  Preparation  of  the  proposal  analysis  for  the 
negotiation  board  -  The  CS  will  prepare  an 
analysis  for  review  by  the  change  order 

negotiation  board.  The  analysis  will  cover  all 
the  preliminary  discussion  between  the  contractor 
and  the  C£/lead  engineer  team. 

9)  Change  order  negotiation  board  meeting  -  The  board 
meets  to  discuss  the  CS's  prepared  analysis  and 


to  determine  if  the  contractor’s  proposal  is  fair 
and  reasonable. 

10)  Board  report  preparation  -  The  CS  prepares  a 
board  report  for  all  the  board  members  to  sign. 

11)  Approval  cf  board  report  -  The  signed  board 
report  is  submitted  to  the  approving  authority 
for  approval. 

12)  Signing  of  the  Change  Order  -  The  approving 
authority  signs  the  Change  Order  for  the 
government. 

13)  Contractor  sent  Change  Order  -  The  signed  Change 
Order  is  sent  to  the  contractor. 

111. 8  Progress  Payments  -  Periodically  the  contractor  will 
submit  a  request  for  a  progress  payment  to  the  CS.  The 
CS  will  obtain  an  endorsement  from  the  lead  engineer  on 
the  request.  Based  upon  the  lead  engineer’s  endorsement 
and  upon  the  CS’s  own  knowledge  of  the  progress  cf  the 
contractor,  the  CS  will  forward  the  request  for  payment 
to  the  proper  government  disbursing  office. 

111. 9  Disputes,  errcrs  and  omissions,  design  deficiencies, 
A-E  liability  -  The  Contracting  Officer,  CS,  lead 
engineer,  and  the  contractor  will  be  involved  in  the 
resolution  of  these  matters.  These  matters  are  normally 
resolved  at  this  low  level  but  may  progress  through  a 
complex  process  leading  ultimately  to  court  action  if 
necessary. 

III.  10  Final  Payment  -  When  all  design  work  has  beer, 
completed  and  accepted  by  the  government,  the  contractor 
will  submit  his  request  for  the  final  contract  payment. 
This  payment  is  processed  in  a  similar  manner  as 
progress  payments  except  that  the  contractor  is  paid  the 
full  remaining  balance  of  the  contract  fee  with  no 
contingency  withheld. 


III.  11  Contractor  Release  -  The  contractor  is  released  from 
the  provisions  of  the  contract  once  all  work  has  been 
completed  and  final  payment  has  been  made. 

III.  12  A-E  Performance  Report  (DD  14  13)  -  The  A-E 

performance  report  is  a  summary  of  the  contractor’s 
performance  during  the  life  of  a  particular  contract. 
The  CS  will  require  the  lead  engineer  to  fill  out  the  DD 
1413.  This  report  will  remain  in  the  contractors  file 
for  future  reference  on  other  contract  considerations. 


V.  RE£OI RESENTS  DETERMINATION 


A-  NHY  AN  AUTOMATED  SYSTEM? 

The  NAVFAC  history  on  Automated  Data  Processing  as 
mentioned  earlier  goes  back  to  the  1950*3.  ADF  has  progres¬ 
sively  proven  to  be  a  more  advantageous  tool  to  use  in  the 
area  of  facilities  management.  The  Naval  Facilities  System 
has  been  built  around  the  concepts  of  ADP  and  the  emerging 
technologies  of  the  computer  revolution.  One  goal  of  the  NFS 
is  to  extend  the  management  resources  available  to  the  field 
activities.  This  process  of  distributing  the  ADP  capabili¬ 
ties  is  evolutionary  in  nature  with  the  EFDs  becoming 
increasingly  more  ADP  oriented.  The  next  phase  of  the  evolu¬ 
tion  is  to  reach  the  commands  and  field  activities  supported 
by  the  EFD.  Several  of  the  EFDs  have  begun  to  provide  the 
field  activities  with  computer  hardware  and  software  which 
will  enable  them  to  develop  applications  on  the  local  level 
as  well  as  communicate  directly  with  the  EFDs.  Most  of  the 
communications  planned  will  require  use  of  commercial  tele¬ 
communication  lines  for  distributed  processing.  Unlike  field 
activities  in  the  continental  United  States,  overseas  activ¬ 
ities  have  problems  with  this  form  of  communication.  The 
costs  and  reliability  factors  as  well  as  protocol  complica¬ 
tions  make  transoceanic  telecommunication  of  data  imprac¬ 
tical  at  this  time.  These  activities  must  depend  therefore 
on  local  independent  computer  systems. 

Automation  is  not  appropriate  for  every  situation.  For 
some  processes,  total  automation  can  be  achieved  and  will 
result  ir  many  benefits,  while  other  processes  do  not  lend 
themselves  to  automation  and  should  remain  manual.  The  A-E 
contracting  process  falls  in  the  middle  of  the  spectrum. 
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There  are  several  benefits  the  EOICC  can  gain  by  automating 
portions  of  the  process.  Consider  the  following: 

Time  Savings  -  The  k- E  management  procedures  require  a 
sizeable  amount  of  correspondence,  reports  and  stan¬ 
dard  memorandums.  In  an  automated  system  form, 
letters,  reports  and  memorandums  are  required  to 
only  be  written  one  time.  Form  correspondence  such 
as  this  only  requires  that  unique  information  be 
inputted.  This  input  can  be  made  either  from  a  data¬ 
base  or  in  response  to  on-line  queries.  In  advanced 
electronic  office  environments,  much  of  the  in-house 
correspondence  can  be  sent  via  electronic  mail 
producing  time  savings  for  both  staff  and  managerial 
personnel.  In  considering  the  time  required  to 
locate  information  in  a  file,  a  computer  based 
system  utilizing  a  database  management  system  can 
provide  the  information  by  simply  responding  to  a 
query.  The  computer  will  locate  the  information  as 
opposed  to  an  individual  having  to  manually  look 
through  a  physical  file. 

Accuracy  -  There  is  a  potential  for  greater  accuracy. 
Once  the  data  is  entered  into  the  system  in  the 
proper  format,  it  is  not  necessary  to  reenter  it. 
This  reduces  the  number  of  times  the  data  needs  to 
be  physically  handled.  Selective  user  interfaces 
and  error  reducing  screen  formats  can  aid  greatly  in 
reducing  the  number  of  data  entry  errors. 

Data  Collection  -  Methods  for  collecting  the  data  can  be 
much  faster  than  manual  systems.  User  interfaces  can 
be  designed  to  prompt  the  user  for  the  data. 
Properly  designed  prompts  and  input  screens  remove, 
in  a  number  cf  cases,  any  questions  staff  personnel 
have  regarding  the  proper  data. 


Data  Storage  -  Manual  systems  require  the  collection  of 
a  high  volume  of  redundant  data.  Computer  based  data 
storage  can  utilize  database  management  systems 
which  will  greatly  reduce  the  need  for  redundant 
data.  As  mentioned  earlier,  data  in  one  database  car. 
be  utilized  to  satisfy  more  than  one  requirement. 
This  also  reduces  the  size  of  the  data  storage.  As 
an  example,  in  the  contract  process,  the  name  of  a 
contractor  normally  appears  on  most  of  the  contract 
documentation.  With  a  database  management  system, 
the  storage  of  this  information  would  only  be 
required  once,  follow-on  reports  or  correspondence 
could  be  provided  the  contractor’s  name  from  the 
database. 

Personnel  Turnover  -  In  many  cases  an  automated  system 
can  ease  the  problems  associated  with  the  turnover 
of  personnel.  The  automated  system  if  properly 
designed  can  guide  new  personnel  in  the  work 
process.  With  built-in  help  facilities,  the  computer 
can  be  referenced  when  questions  arise.  Also  for 
data  entry,  set  formats  provide  the  new  personnel 
with  a  template  for  input  process,  removing  seme  of 
the  ambiguity  of  a  new  system. 

Costs  -  Most  improvements  to  a  process  result  in  cost 
savings.  Computer  based  systems  are  no  exception  if 
they  are  properly  designed  to  fit  both  the  organiza¬ 
tional  needs  and  the  process.  Cost  savings  are  seen 
in  personnel,  supplies  (less  paper  in  some  systems), 
and  time  savings  from  data  entry,  storage,  and 
retrieval. 
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B.  THE  COMPOTE?. -BAS EE  ENVIRONMENT 


For  the  proposed  automated  A-E  contract  management 
[(  process  to  be  effective,  it  should  provide  the  benefits 

described  above.  Aron  [Ref.  8:  pp.  213-236]  describes  three 
levels  cf  information  system  design  for  organizational 
information  systems.  The  levels  are: 

1)  simple  data  processing  system 

2)  integrated  file-oriented  data  processing  system 

3)  management  information  system 
A  fourth  level  would  be  information  resources  management 
systems  (IRMS) ,  a  concept  on  the  current  edge  of  information 
systems  technology.  Each  of  the  higher  level  systems 
include  the  elements  of  the  lower  level  systems  since  the 
development  of  the  systems  from  the  first  to  the  fourth  has 
occurred  in  an  evolutionary  process.  Let's  consider  each 
level  individually  in  relationship  to  the  A-E  contract 
management  process. 

1.  Simple  Data  Processing  System 

The  simple  data  processing  system  consists  of  a 
number  of  independent  transaction-oriented  tasks  which 
summarize  inputs  to  produce  reports.  The  ROICC  may  want  to 
know  at  the  conclusion  of  the  fiscal  year  how  many  contracts 
were  awarded  for  A-E  services.  A  simple  data  processing 
system  approach  to  this  request  is  shown  in  Figure  5.1. 
Curing  the  year,  as  each  contract  is  awarded,  an  input  could 
be  made  into  a  computer  which  would  give  the  data  for  the 
contract  such  as  the  contract  number,  title,  A-E  firm  and 
the  fee.  A  program  cculd  be  written  to  take  this  input  and 
produce  a  report  at  the  end  of  the  year  which  would  summa¬ 
rize  the  number  of  ccntracts  and  the  total  dollar  amount  of 
fees  awarded.  This  same  approach  could  be  made  for  a  number 
of  desired  reports.  The  disadvantage  of  this  type  of  system 
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Figure  5.1  Simple  Data  Processing. 

is  that  the  reports  are  historical  in  nature  and  tend  to 
provide  cnly  record  type  information.  Simple  data  processing 
systems  which  produce  historical  data,  do  not  lend  them¬ 
selves  to  the  day  to  day  dynamic  management  requirements  of 
the  BCICC. 

2.  Integrat ed  File-Oriented  Data  Processing  S  /stem 

Most  shortcomings  of  the  data  processing  system  are 
overcome  by  the  development  of  the  integrated  file-oriented 
data  processing  system.  The  integrated  file-oriented  data 
processing  system  structures  data  such  that  facts  can  be 
extracted  according  tc  many  different  criteria.  A  contractor 
information  system  maintained  by  the  ROICC  can  contain  data 
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on  contractors  who  either  do  business  with  the  Government  or 
who  desire  to  be  considered  for  upcoming  contracts.  The  data 
is  stored  in  a  series  of  files  made  up  from  information  the 
contractor  has  submitted  via  the  SF  254  and  possibly  the  S? 
255.  These  forms  provide  demographic  information  on  the 
contractor  as  well  as  the  composition  of  the  firm  by  disci¬ 
pline  and  a  short  concise  history  of  the  firm's  past 
contract  experience.  The  ROICC  utilizing  an  integrated  file- 
oriented  data  processing  system  can  determine  for  example 
which  contractors  on  record  have  the  proper  mix  of  engi¬ 
neering  disciplines  to  perform  a  certain  contract.  This 
would  be  accomplished  as  shown  in  Figure  5.2.  The  data  from 
the  SFs  would  be  inputted  to  database  files  as  the  forms  are 
received  by  the  ROICC.  A  series  of  program  would  be  used  by 
a  supervisory  program  to  select  and  extract  the  needed 
information  from  the  proper  data  files  in  the  database.  The 
output  would  be  formatted  by  one  of  the  programs  in  the 
series  and  produced  either  as  a  newly  created  file  or  as  a 
hardcopy  report  or  as  both. 

3.  Management  Information  System 

The  MIS  adds  another  block  to  the  information  system 
structure.  The  MIS  adds  the  foreknowledge  of  what  decisions 
must  be  made  by  the  ROICC  in  managing  the  contracting 
process.  The  MIS  is  an  integrated  system  for  providing 
information  to  support  planning,  control,  and  the  operation 
of  the  ECICC  shop.  Figure  5.3  shows  the  basics  of  a  typical 
MIS.  The  MIS  combines  the  data  bases  of  the  integrated 
file-oriented  system  with  a  database  of  inference  models  and 
models  for  evaluation  criteria.  Application  proy ra ms  kept  on 
file  are  utilized  to  draw  data  from  the  three  databases  to 
assist  the  F.OICC  in  making  decisions.  The  ROICC  using  a  MIS 
could  be  guided  to  the  proper  reports  required  by  a  certain 
contract  type  or  size.  The  MIS  would  evaluate  the  contract 
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approvals  would  be  required.  The  MIS  would  make  tais 
requirement  known  and  then  would  proceed  to  collect  the 


information  from  the  main  database  to  create  the  report  and 


produce  it  either  for  viewing  on  a  CRT  or  in  hardcopy. 
4.  Information  Resource  Management  System 


The  Information  Resource  Management  System  (IRMS)  is 
the  current  technology  in  information  systems.  The  system  is 
the  convergence  of  several  information  technologies,  data 
processing,  communications  and  the  automated  office.  In  the 
future,  IRMS  will  permit  the  ROICC  to  teleconference  with 
the  EFD  and  possibly  permit  the  Award  Board  to  interview  the 
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contractor  via  teleccnf erencing .  Most  transactions  in  the 
contracting  process  would  be  accomplished  without  paper.  All 
draft  SOWs,  drawings  and  payment  reguests  would  be  trans¬ 
mitted  electronically.  The  futuristic  IRMS  would  extend  the 
MIS  capabilities  so  that  Decision  Support  Systems  would  be 
available  to  the  ROICC  from  EFD  resources. 

C.  ROICC  A-E  COHTBACTIHG  MIS 

The  IRMS  is  technologically  in  the  future  for  the  ROICC 
and  for  NAVFAC  as  a  whole.  The  data  processing  system  and 
the  integrated  file  oriented  processing  systems  seem  only  to 
automate  a  currently  manual  system  rather  than  provide  an 
improved  management  tool.  The  complete  contract  management 
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function  of  the  EOICC  which  includes  A-E  and  construction 
contracting  management  would  he  well  supported  by  a  HIS.  The 
A-E  contract  management  process  would  be  only  part  of  that 
system. 

The  system  to  support  the  EOICC  MIS  should  enable  the 
EOICC  to  do  basic  word  processing,  database  management,  and 
run  applications  to  interface  the  database  and  the  applica¬ 
tion  programs.  The  size  of  the  system  would  depend  primarily 
on  the  size  of  the  contract  management  task.  The  applica¬ 
tions  could  consist  cf  different  modules:  1)  to  handle 
report  and  letter  generation;  2)  to  track  the  individual 
contract  phases;  3)  to  track  the  contract  workload;  and  4) 
to  run  rule  based  modules  to  assist  the  EOICC  in  deciding 
where  and  when  to  apply  various  regulations.  ?ith  the  addi¬ 
tion  of  communication  technologies,  the  system  could  be 
connected  to  the  engineering  department  so  that  requirements 
such  as  SOWs  and  government  estimates  could  be  transmitted 
electronically.  Further  communication  capabilities  would 
enable  the  EOICC  to  send  reports  and  copies  of  contracts  to 
the  EFD  electronically. 

D.  PBOPCSED  A-E  CONTEACTING  SYSTEM 

The  following  three  cnapters  present  a  proposed  auto¬ 
mated  A-E  Contract  Management  System  beginning  with  the 
pre-negotiation  phase  and  concluding  with  the  post-award 
phase.  The  proposed  system  is  based  on  the  idea  of  using  a 
micro-computer  and  running  commercially  available  software 
to  develop  application  modules.  The  concepts  used  to 
develop  the  framework  of  the  system  are  those  discussed 
above.  The  approach  taken  in  the  proposal  is  not  the  only 
one  that  will  produce  a  useable  automated  A-E  MIS.  It  will 
provide  the  field  with  a  useful  management  tool  at  a  minimal 
cost  through  available  current  technology.  As  will  be 


discussed  later,  the  hardware  and  software  utilized  to 
implement  the  proposed  system  can  be  used  by  the  field 
activity  in  other  ways.  As  an  example  of  how  such  a  system 
could  be  developed  and  might  function,  one  major  module  of 
the  proposed  system,  the  contractor  Information  System 
(CIS),  has  teen  developed  and  is  presented  in  Appendix  A. 


71.  AUTOMATIC]}  OF  THE  PRErilGOIIiTION  PHASE 

The  Pre-Negotiaticn  Phase  will  be  the  initiation  phase 
of  the  majority  of  the  automation  of  the  entire  management 
information  process.  Some  functions  for  this  phase  will  also 
be  carried  into  the  second  and  third  phases.  Each  step  will 
be  investigated  for  possible  automated  procedures  in  the 
areas  of  applications,  report  generation  and  database  appli¬ 
cations.  As  will  be  seen,  many  of  the  automation  procedures 
will  reguire  the  interface  of  these  three  areas  for  effec¬ 
tive  building  of  management  tools  and  improvements  for  the 
office  staff. 

A.  BEQUEST  FOB  CONTEACT  (I.  1) 

The  contracting  officer  after  receiving  the  recuest  for 
contract  can  initiate  two  automated  management  tools,  the 
phase  1/11  tracking  database  and  the  contract  file.  The 
tracking  database  tracks  the  administrative  contracting 
steps  of  phase  I  and  II  and  is  driven  by  an  application 
module  which  guides  the  user  through  the  proper  control 
measures.  The  database  would  contain  a  listing  of  all  the 
contracting  steps  with  an  estimated  completion  time  calcu¬ 
lated  automatically  by  the  driver  application.  The  base  of 
the  completion  times  would  be  provided  by  the  contracting 
officer.  This  aspect  of  the  tracking  system  would  permit  the 
contracting  officer  to  vary  the  times  based  on  the  condi¬ 
tions  at  hand  (i.e.  year-end  obligations,  predetermined 
performance  criteria,  etc.).  As  the  steps  are  completed,  the 
appropriate  dates  car  be  entered  into  the  database  ty  an 
automated  timestamp. 
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Another  feature  cf  the  tracking  system  is  the  tickler 
function.  This  function  permits  the  user  to  enter  the 
current  date  and  be  given  a  listing  of  all  actions  which  are 
due  to  be  completed  cn  that  day  and  present  a  listing  of  the 
delinquent  actions  and  signify  if  there  is  a  comment  in  the 
file  explaining  the  variance.  Since  delays  can  be  expected, 
provisions  exist  for  the  user  to  adjust  the  schedule.  A  log 
in  the  database  will  be  maintained  to  record  adjustments  for 
historical  purposes. 

The  second  management  tool  is  the  contract  file  which  is 
simply  an  electronic  file  of  contract  documents  and  check¬ 
lists.  The  contract  file  is  not  a  static  depository  of 
electronically  produced  documents,  but  along  with  specific 
application  programs  will  become  the  most  extensively  used 
management  tool  for  the  CS  and  contracting  officer.  The 
checklists  in  the  file  will  aid  the  CS  in  the  contracting 
process.  Many  documents  will  be  placed  in  this  file  by 
various  application  programs.  The  file  will  be  updated  on 
many  occasions  automatically  by  the  application  programs. 
Access  to  the  file  is  limited  by  procedures  described  below. 

E.  CCNTEACT  SPECIALIST  ASSIGNED  (1.2) 

The  contracting  officer  will  maintain  a  database  of  the 
CSs  in  the  organization  and  the  contracts  they  are  assigned. 
He  will  update  the  database  as  a  new  assignment  is  made  as 
well  as  update  the  contract  file  to  indicate  the  CS 
assigned.  This  update  to  the  contract  file  is  part  of  the 
security  measures  of  the  system.  Only  certain  personnel 
determined  by  the  contracting  officer  can  access  the 
contract  file  for  a  particular  contract.  Each  CS  and  staff 
person  is  assigned  a  personal  password.  To  gain  entry  to 
specific  files  the  person  desiring  entry  must  first  get 
through  a  password  checking  module.  Limitations  in  file 
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entry  can  be  no  access,  read  only  access  or  full  access 
which  allows  both  read  and  write  access.  The  access  tc  the 
file  can  be  changed  at  anytime  by  the  contracting  officer  or 
a  designated  assistant. 

The  first  form  letter  from  the  report  file  is  initiate! 
upon  the  assignment  of  the  CS.  The  contracting  officer 
initiates  a  letter  to  the  customer  informing  him  of  the 
acceptance  of  the  contract  reguest,  the  CS  assigned,  the 
contract  number  and  also  the  need  for  a  complete  SOW  and 
government  estimate  (if  the  customer  is  the  engineering 
department,  otherwise  the  CS  will  ensure  that  the  government 
estimate  is  developed) .  The  basic  form  of  the  letter  is 
contained  in  a  report  generator  file.  This  file  is  a  collec¬ 
tion  of  all  the  reports  and  letters  required  during  the 
entire  contract  process.  The  user  is  given  the  option  when 
using  the  form  letters/reports  to  input  the  information 
using  a  word  processor  type  entry  or  to  let  the  system 
extract  the  information  from  the  various  databases  in  the 
system.  For  example,  the  letter  to  the  customer  can  obtain 
the  contract  number  and  the  CS  assigned  from  the  contract 
file.  The  contracting  officer  needs  only  to  identify  the 
correct  contract  file. 

C.  DEVE10PHENT  OF  STATEMENT  OF  WORK  (1.3) 

The  SOW  may  be  written  by  the  customer  using  a  word 
processor  and  transmitted  to  the  contract  office  via  modem 
or  by  sending  a  copy  on  a  floppy  disk  to  the  CS.  The  CS  can 
proceed  to  use  a  word  processor  to  proof  the  SOW  and  make 
the  appropriate  changes  then  return  the  SOW  to  the  customer 
in  a  similar  manner.  If  the  SOW  is  electronically  produced 
it  can  be  placed  into  the  contract  file.  If  not,  a  duplicate 
physical  file  will  have  to  be  maintained  for  any 
non-electronically  produced  documents. 


D.  DETAILED  GOVERNBENT  ESTIMATE  (1.4) 


An  application  nodule  maintained  by  the  contracting 

staff  will  be  available  for  use  by  the  engineering  staff  to 

develop  the  estimates.  The  module  will  permit  the  estimator 

to  access  a  database  of  standard  costs  for  various  labor 

categories.  A  cost  estimate  worksheet  will  be  provided  the 

estimator  from  the  reports/letters  file  which  permits  the 
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estimator  to  build  the  estimate  from  the  labor  costs  data¬ 
base.  The  estimator  application  module  allows  the  estimator 
to  enter  a  labor  class  and  estimated  effort  from  which  the 
total  cost  for  that  labor  class  will  be  calculated.  The 
module  will  supply  the  current  applicable  overhead,  Gf-A,  and 
other  fees  and  calculate  the  bottom  line  figures.  The  esti¬ 
mator  is  provided  the  flexibility  to  change  any  estimate 
entered  and  request  another  calculation  of  the  total.  The 
estimate  can  then  be  electronically  transmitted  to  the  CS . 

E.  REQUIRED  CLEARANCES  AND  APPROVALS  (1.5) 

Based  on  the  provided  government  estimate,  the  CS  can 
utilize  a  rule-based  decision  module  to  determine  which 
clearances  and  approvals  are  required  for  the  procurement 
action.  The  ruled-tase  is  maintained  by  the  contracting 
staff  to  reflect  current  contracting  regulations.  The  CS 
would  be  guided  through  a  series  of  possible  requirements. 
If  the  module  determines  a  clearance  or  approval  is 
required,  the  CS  determines  if  the  report  or  letter  should 
be  prepared.  If  the  report/letter  is  to  be  prepared,  the 
report/letter  file  is  accessed  for  the  proper  format  and  the 
information  required  can  be  obtained  from  the  various  data¬ 
bases  or  alternately  may  be  provided  by  the  CS.  In  the 
former  case,  the  CS  will  be  prompted  for  the  information  and 
be  given  the  format  for  the  information  if  a  specific  format 
is  reguired.  Copies  of  any  correspondence  will  be  placed  in 
the  contract  record  data  file. 
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F.  SMALL  BUSINESS  SET  ASIDE  RECOMMENDATION  (1.6) 

This  recommendation  will  be  a  part  of  the  rule-based 
module  described  above.  Once  the  decision  is  made,  the 
contract  file  will  be  updated  to  reflect  the  decision. 

G.  COMMERCE  BUSINESS  DAILY  SYNOPSIS  (1.7) 

The  CS  will  call  up  from  the  report/letter  file  the 
format  for  the  letter  to  the  Commerce  Business  Daily.  The 
basic  form  such  as  the  address  and  standard  verbiage  will  be 
on  the  letter.  The  CS  using  a  word  processor  can  fill  in  the 
body  of  the  letter  with  the  information  concerning  the 
proposed  contract  then  print  a  hard  copy  and  mail  it  to  the 
CBD .  A  copy  of  the  CEE  announcement  letter  will  be  placed  in 
the  contract  file. 

H.  LOGGING  OF  SF  254  AND  SF  255  (1.8) 

The  SF  254/255  provides  information  on  the  contractor 
and  the  firm’s  history  of  performance.  The  CS  or  a  staff 
assistant  will  enter  the  summary  information  from  the  forms 
into  the  Contractor  Information  System  (CIS)  database.  The 
application  module  permits  a  number  of  functions  to  be 
performed  on  the  CIS  database.  These  include  adding, 
changing,  deleting,  viewing  and  printing  of  reports.  A 
sample  of  an  operational  CIS  application  module  is  presented 
in  Appendix  A.  An  important  aspect  of  the  design  of  this 
application  module  is  the  data  design  and  description.  The 
Contractor  Information  System  is  a  NAVFAC  system  included  as 
part  of  the  NFS.  The  data  collected  in  this  module  must  be 
as  near  as  possible  to  the  data  format  and  descriptions  as 
used  in  the  NFS.  This  compatibility  will  insure  that  when 
future  transmission  of  information  between  the  EFD  or  FACSO 
becomes  a  reality,  there  will  be  minimal  interface  problems 
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and  adjustments.  The  details  of  the  CIS  are  discussed  in  the 
Appendix  A. 

The  CS  or  contracting  officer  can  use  the  CIS  for  devel¬ 
oping  bidder’s  lists  for  specific  contract  requirements. 
This  is  especially  important  to  have  in  the  advent  of  urgent 
design  projects  which  must  be  accomplished  under  exceptional 
circumstances.  Contractors  who  have  previously  submitted  the 
SF  254  need  not  be  reentered  into  the  CIS.  Their  file  will 
only  require  updating.  Onder  normal  conditions,  most 
contracting  offices  have  a  stable  base  of  contractors  who 
continuously  bid  on  contracts.  This  reduces  the  number  of 
first  time  entries  into  the  CIS. 

I.  BOAR!  APPOINTMENT  LETTERS  (1.9) 

A  database  is  maintained  listing  the  eligible  board 
members  and  the  current  boards  they  are  sitting  on  as  well 
as  the  last  concluded  board  they  sat  on.  A  board  member 
selection  module  will  permit  the  selection  of  the  members 
from  the  list  simply  by  indicating  an  identifier  (number  or 
letter).  The  module  will  then  access  the  reports/letters 
file  and  extract  the  notification  letter  for  the  board 
members.  The  letters  will  be  printed  out  automatically  or 
transmitted  to  the  member's  office  if  electronic  mailing 
systems  are  in  use.  The  contract  file  will  be  automatically 
updated  to  indicate  the  pre-selection  board  members. 

J.  PRE-SELECTION  (1.10) 

The  reports/letters  file  contains  a  form  pre-selection 
board  letter.  This  form  letter  can  be  used  by  the  Board  to 
record  the  Eoard  meeting  results.  The  CS  upon  receiving  the 
results  of  the  board  and  an  authorized  signature  ccpy  of  the 
board  report  will  update  the  contract  file  with  a  copy  of 
the  board  report. 


All  during  the  pre-negotiation  phase  the  contract 
tracking  system  has  teen  operational.  The  updates  tc  this 
tracking  system  can  either  be  performed  automatically  by  the 
master  module  of  the  contracting  MIS  or  by  the  CS  as  the 
steps  are  completed.  This  tracking  system  is  carried  through 
to  the  Negotiation  Phase. 
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VII.  AOTOMAIION  OF  THE  NEGOTIATION  PHASE 
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Transition  to  the  second  phase  of  the  A-E  contracting 
phase  frcm  the  first  phase  is  transparent  to  the  user.  The 
same  proposed  tracking  system,  databases  and  the  reports/ 
letters  file  are  used.  In  fact  the  main  driver  program  for 
the  application  modules  is  still  in  use. 

A.  INTERVIEW  LETTERS  (II.  1) 

The  pre-selecticn  board  report  produced  the  slate  of 
contractors  to  be  considered  in  the  interviewing  process  of 
the  negotiation  phase.  The  names  of  these  contractors  were 
placed  in  the  contract  file  as  the  closing  action  of  the 
first  phase.  The  CS  can  retrieve  the  form  interview  letter 
from  the  reports/letters  file.  The  contractors  names  can  be 
extracted  from  the  contract  file.  The  addresses  of  the 
selected  contractors  can  be  extracted  from  the  CIS  database. 
The  CS  will  more  than  likely  schedule  the  interviews  around 
the  availability  of  the  board  members  and  the  contractors. 
Cnee  a  schedule  has  teen  established,  the  CS  will  note  the 
times  and  place  of  the  interviews,  print  the  letters  and 
send  them  to  the  contractors.  A  schedule  of  the  interviews 
will  be  maintained  in  the  contract  file. 

B.  INTERVIEW  OF  THE  A-E  FIRMS  (II.  2) 

Several  items  can  be  included  in  this  step  of  the 
process  but  all  the  automated  options  are  at  the  discretion 
of  the  contracting  officer.  A  form  interview  evaluation 
sheet  can  be  maintained  in  the  reports/letters  file.  This 
type  of  uniform  evaluation  focus  can  ensure  that  all  the 
board  members  evaluate  the  proper  aspects  of  the  contractor. 


This  fern  would  be  used  in  conjunction  with  the  predefined 
evaluation  criteria.  The  evaluation  would  be  a  standard  form 
used  for  all  contract  interviews.  A  listing  of  instruction 
to  the  interviewers  can  also  be  prepared  and  maintained  in 
the  file.  If  a  standard  evaluation  algorithm  is  used  by  the 
board  to  determine  the  best  qualified  contractor,  a  module 
can  be  provided  to  calculate  the  results.  While  this  would 
provide  an  analytically  determined  best  qualified 
contractor,  it  is  probably  only  a  good  starting  point  for 
discussion  by  the  selection  board. 

C.  SE1ECTION  OF  A  CCSTRACTOR  {II. 3) 

Once  the  board  determines  from  the  interviews  who  the 
best  qualified  contractor  is,  a  board  report  must  be 
produced  for  approval  of  the  selection.  Again  the  CS  or  the 
head  of  the  board  can  retrieve  a  form  letter  from  the 
reports/letters  file.  The  heading  and  boilerplate  informa¬ 
tion  will  already  be  on  the  letter  and  the  CS  can  use  a  word 
processor  to  fill  in  the  remainder  of  the  letter  based  on 
the  findings  of  the  board.  After  the  selection  has  been 
approved  by  the  approval  authority,  the  contract  file  will 
again  be  updated  by  the  CS. 

D.  REQUEST  FOR  FEE  PROPOSAL  (II. 4) 

The  selected  contractor  is  supplied  with  a  standard 
government  estimate  form.  This  ensures  consistency  between 
the  format  of  the  contractors  estimate  and  the  government 
estimate.  The  estimation  form  and  the  letter  to  forward  the 
form  to  the  contractor  are  both  contained  in  the  reports/ 
letters  file.  The  CS  can  add  any  instructions  and  comments 
that  are  deemed  appropriate  for  the  particular  contract. 

If  the  contract  is  of  sufficient  size,  various  forms  and 
certificates  will  be  required  of  the  contractor.  A 
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rule-based  nodule  will  again  be  employed  to  assist  the  CS  ir. 
determining  which  forms  and  certificates  are  required  or  the 
contractor.  The  module  will  automatically  retrieve  any 
required  forms  and  will  also  signify  which  certificates  are 
necessary. 

E.  EECEIPT  OP  THE  FEE  PROPOSAL  (II. 5) 

Cnee  the  fee  proposal  is  received  by  the  CS,  the 
contract  file  is  updated  to  show  the  receipt.  The  lead  engi¬ 
neer  (on  the  board)  will  review  and  compare  the  estimates.  A 
spreadsheet  type  module  could  be  developed  for  use  in  this 
comparison  process.  The  module  would  evaluate  the  differ¬ 
ences  in  particular  items  on  the  estimates.  This  however  is 
not  recommended  since  in  most  instances  the  estimates  will 
vary  in  the  classes  of  labor  that  will  be  used.  It  would  be 
comparing  dissimilar  items  which  is  no  comparison.  The 
expense  of  development  and  the  overhead  of  maintaining  such 
a  module  probably  could  not  be  justified. 

The  amount  of  the  fee  may  require  that  other  clearances 
be  obtained.  A  rule-based  module  will  again  be  used  to 
assist  the  CS  in  identifying  the  clearances  needed.  If  forms 
are  needed  they  will  be  produced  along  with  a  forwarding 
letter  to  the  contractor. 

F.  PRE-NEGOTI ATIOH  (II. 6) 

No  automation  is  needed  i.  this  step  except  for  possibly 
the  writing  of  memorandums  ising  a  word  processor.  The 
letter  would  be  a  record  of  any  pre-negotiation  discussions 
the  CS  or  engineers  have  with  the  contractor.  These 
documents  would  be  filed  in  the  contract  file. 


G.  NEGOTIATION  BO ARE  MEETING  (II. 7) 


The  negotiation  hoard  report  form  letter  is  maintained 
in  the  reports/letters  file.  The  CS,  upon  completion  of  the 
negotiations  with  the  contractor  and  agreement  between  the 
hoard  members,  will  prepare  the  board  report  using  a  worl 
processor  to  fill-in  the  form  letter.  The  letter  would  then 
he  forwarded  to  the  approval  authority  for  signature. 

H.  NEGOTIATION  BOARD  REPORT  APPROVAL  (II. 8) 

Since  this  function  occurs  outside  of  the  contracting 
office  in  most  cases,  no  automation  is  required.  However,  if 
electronic  mail  is  in  use,  the  letter  can  be  sent  through 
this  system.  Signatures  in  an  electronic  mail  system  can  be 
implemented  through  the  use  of  specially  assigned  password 
type  keys.  For  example,  unique  control  sequence  entries  into 
the  designated  signature  block  of  the  letter  can  he  recorded 
hut  not  seen.  The  tail  or  head  of  the  control  sequence  can 
contain  the  visible  initials  or  name  of  the  person  whose 
unseen  signature  is  present.  A  module  can  be  used  in  the 
system  tc  decipher  the  signature  for  verification  purposes. 

I.  CONTRACT  AHARD  (II.  9) 

The  approved  contract  award  report  is  filed  in  the 
contract  file.  This  step  requires  the  CS  to  build  the 
actual  contract  by  using  an  on-line  file  of  standard  provi¬ 
sions  and  special  previsions.  The  CS  can  place  all  the 
required  contract  documentation  in  a  single  working  file  and 
upon  completion  have  the  the  contract  printed.  The 
contracting  office  ccpy  of  the  contract  need  not  be  printed 
since  it  will  be  placed  in  the  contract  file  and  can  be 
reviewed  at  any  time  hy  the  contracting  staff.  The  complete 
contract  can  then  he  forwarded  to  tne  contractor  for 
signature. 
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Till.  AUTOMATION  Of  Til  POST-AWARD  PROCESS 


The  end  of  the  second  phase  is  also  the  end  of  the 
proposed  tracking  system  used  in  the  first  two  phases.  A  new 
proposed  tracking  system  is  initiated  at  the  beginning  of 
the  third  phase  of  the  A-E  contracting  process  which  is 
similar  to  previous  one  with  the  exception  being  the  things 
that  are  tracked.  The  tracking  database  contains  the 
project  number  and  title  (relating  to  any  special  project 
designs  that  are  being  accomplished),  contract  number,  A-E’s 
name  and  number,  fee  for  the  design,  current  working  esti¬ 
mate,  engineer  in  charge  of  the  design  effort  and  the  award 
date  of  the  contract.  Dates  to  be  tracked  are  the  scheduled 
and  actual  submittal  dates  for  the  30%,  60%,  90%,  and  100% 
from  the  contractor  as  well  as  the  comparable  dates  for  the 
government  review  process  of  the  contractor’s  work. 

This  tracking  system  is  initiated  by  the  CS  with  the  aid 
of  a  module  which  actually  creates  the  database  from 
existing  databases  and  the  contract  file  once  the  CS  signi¬ 
fies  which  contract  is  to  be  tracked.  The  tracking  system 
can  be  used  by  the  contracting  officer  or  the  CS  tc  see 
which  actions  are  required  to  be  completed  on  a  certain  day. 
The  system  also  provides  a  profile  of  the  actions  due  for 
completion  over  a  specified  period  of  time.  This  feature 
will  be  most  helpful  at  peak  operating  period  such  as  the 
end  of  the  fiscal  year. 

A.  NOTIFICATION  LETTERS  (III.  1) 

The  CS  utilizes  the  reports/letters  file  to  retrieve  the 
notification  letter  format.  In  most  cases,  this  letter  is 
completely  standardized  with  the  only  information  tc  be 


added  being  the  names  of  the  receiving  contractor  and  the 
contractor  who  was  awarded  the  contract.  The  CS  can  either 
put  these  in  using  a  word  processor  or  the  system  can 
perform  this  automatically  by  the  CS  indicating  which 
contractor  was  awarded  the  contract.  The  remainder  of  the 
information  can  be  obtained  from  the  contract  file  where  all 
the  considered  contractors  names  and  addresses  are  listed. 
Copies  of  these  letters  are  not  retained  but  a  notation  is 
made  in  the  contract  file  that  the  letters  were  sent. 

B.  INDIVIDUAL  PROCUREMENT  ACTION  (DD  PORM  350)  (III. 2) 

The  DD  350  reports  to  higher  commands  information 
concerning  individual  procurements.  It  is  to  be  submitted 
the  day  after  a  contract  has  been  awarded.  An  application 
module  is  provided  to  permit  the  CS  to  supply  the  informa¬ 
tion  for  the  completion  of  the  report.  The  format  for  the 
interface  with  the  module  can  take  on  many  forms  depending 
upon  the  design  of  the  system.  One  interface  would  be  for 
the  CS  to  be  prompted  for  the  information  that  is  not 
already  available  in  the  contract  file  or  the  Contractor 
Information  System  database.  For  information  which  already 
exists  the  CS  can  verify  the  correctness.  Once  the  informa¬ 
tion  is  gathered,  a  standard  format  can  be  used  from  the 
reports/letters  file  to  print  the  form.  An  enhancement  would 
be  to  transmit  the  form  electronically  to  either  the  EFD  or 
to  NAVFAC  directly  if  the  communication  resources  are  in 
place.  A  copy  of  the  report  would  be  placed  in  the  contract 
file. 

The  DD  Form  1057  is  a  monthly  summary  of  contracts 
awarded  by  the  activity.  A  similar  procedure  can  be  used  by 
the  contracting  staff  to  produce  this  report.  As  systems 
evolve,  reports  such  as  the  DD  350  and  1057  will  become 
obsolete.  The  information  required  by  the  EFD  and  NAVFAC 
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will  be  available  to  these  upper  levels  of  command  at  all 
times.  Communications  and  networks  will  exist  such  that  the 
application  modules  to  retrieve  the  information  currently 
provided  by  these  reports  will  reside  at  the  level  where  the 
information  is  required.  These  modules  will  be  able  to 
access  specially  designated  databases  at  the  field  levels 
whenever  the  data  is  desired. 

C.  CTHEB  BEPOBTS  (III.  3) 

As  mentioned  in  the  other  two  phases,  rule-based  appli¬ 
cation  modules  will  determine  which  reports  are  required  for 
the  individual  contracts.  These  modules  will  indicate  the 
required  reports  and  guide  the  CS  in  preparing  them  for 
submission.  The  report  formats  themselves  will  reside  in  the 
reports/letters  file.  Any  reports  submitted  will  be  filed  in 
the  contract  file. 

D.  BIST BIB OTIOH  OF  CCHTRACT  (III. 4) 

Copies  of  the  contract  will  be  sent  to  various  parties. 
If  the  parties  to  receive  the  copies  have  electronic  mailing 
systems,  the  copies  can  be  sent  this  way  expediting  the 
mailings  and  reducing  the  mailing  costs  as  well  as  aiding  in 
the  storage  of  such  documentation  at  the  receiving  end.  ^any 
EFDs  require  a  copy  of  each  contract  awarded  so  information 
can  he  obtained  for  reference  purposes.  This  procedure  may 
change  in  the  future  as  the  information  transfer 
possibilities  are  expanded. 

Z.  CCHTBACTOB  MEETIHGS  (III. 5) 

These  meetings  may  occur  for  a  variety  of  reasons  and 
all  should  be  documented.  The  engineer  or  the  CS  could  use 
the  word  processor  to  record  the  events  of  the  meeting.  A 


copy  cf  the  meeting  minutes  will  be  placed  in  the  contract 
file.  Seme  contracts,  especially  those  with  a  first  time 
contractor,  require  a  preliminary  meeting  to  discuss  stan¬ 
dard  administrative  items.  Checklists  to  cover  the  require¬ 
ments  cf  the  meeting  can  be  maintained  in  the 
reports/letters  file  for  use  by  the  CS  or  engineer  as  a 
guide  for  the  meetings. 

F.  DESIGN  BEVIEWS  (III. 6) 

The  tracking  system  is  the  key  management  tool  in  this 
procedure.  Other  valuable  computerized  tools  would  be  a 
database  of  the  assigned  drawing  numbers.  This  would  permit 
the  recording  of  the  drawings  numbers  and  titles.  This  data¬ 
base  could  be  expanded  to  act  as  an  index  for  future  refer¬ 
ences  to  the  location  cf  drawings  which  would  be  useful  to 
the  larger  engineering  departments.  The  documentation  which 
accompanies  the  review  process  (comment  sheets  on  submit¬ 
tals)  can  be  maintained  in  their  basic  form  in  the  reports/ 
letters  file. 

G.  CCNTBACT  MODIFICATIONS  (III. 7) 

Contract  modifications  are  not  tracked  on  the  thirl 
phase  tracking  system.  A  note  is  made  on  the  tracking  system 
that  a  modification  is  taking  or  has  taken  place.  It  is 
proposed  that  a  separate  tracking  system  be  established  for 
these  modifications.  This  modification  tracking  database 
would  contain  many  of  the  data  elements  that  the  phase  I  and 
II  system  tracked  including  a  brief  description  of  the  modi¬ 
fication,  contract  number,  dates  (estimated  and  actual)  for 
SOW  and  government  estimate  submission,  request  for  and 
receipt  cf  the  fee  proposal,  negotiation  board  meeting  an i 
the  signing  of  the  change  order.  The  estimated  days  are 
generated  automatically  based  on  past  experience.  The  CS 
will  enter  the  actual  days. 


Beard  member  appointments  and  letters  of  notification 
are  required.  This  is  handled  utilizing  the  same  modules 
that  were  used  in  the  earlier  phases.  The  processing  of  the 
SOtT  and  government  estimate  are  identical  to  step  1.3  and 
1.4.  In  essence,  this  process  follows  the  same  procedures 
as  are  followed  in  the  negotiation  phase  of  the  contract  and 
requires  the  same  management  attention.  For  open-ended 
contracts,  the  modification  process  can  be  in  progress  for 
different  proposed  changes.  This  requires  that  management  of 
the  contract  modifications  be  effective  and  accurate. 


H.  PBOGBESS  PAYMENTS  (III.  8) 

Management  of  the  progress  payment  process  is  oost 
important  for  good  working  relations  with  the  contractor. 
Even  though  the  contracting  office  is  not  the  actual  payer 
of  the  funds,  mismanagement  of  the  request  for  payment  can 
have  damaging  effects.  A  spreadsheet  type  file  is  maintained 
for  the  contract  which  contains  the  dates  and  amounts  of 
requested  payments  as  well  as  the  date  and  amount  of  the 
actual  payments.  The  payment  data  may  be  difficult  to 
obtain  depending  on  the  arrangements  made  between  the 
contracting  office  and  the  paying  office.  This  relationship 
should  be  established  such  that  the  CS  can  obtain  accurate 
information  in  a  timely  manner. 

The  CS  receives  the  request  for  payment  from  the 
contractor.  A  standard  form  from  the  reports/letters  file 
will  be  used  by  the  CS  to  transmit  to  the  lead  engineer  the 
information  regarding  the  payment  request.  The  engineer  must 
annotate  the  form  indicating  his  approval  of  the  percentage 
complete  on  the  project.  This  percentage  is  used  tc  deter¬ 
mine  the  amount  of  the  payment  to  the  contractor.  If  elec¬ 
tronic  mail  is  in  use,  this  process  can  be  accomplished 
electronically.  The  final  copy  of  the  engineer's  annotated 


copy  is  placed  in  the  contract  file.  The  spreadsheet  data¬ 
base  is  updated  on  each  request.  An  application  module 
performs  the  calculations  on  the  amounts  to  be  withheld  and 
amounts  to  be  paid  based  on  predetermined  standards.  The 
system  then  generates  the  proper  form  requesting  the  paying 
activity  to  pay  the  contractor  the  specified  amount  or 
transmitted  electronically  to  the  disbursing  agent. 

I.  DISPUTES,  ERRORS,  OMISSIONS,  DESIGN  DEFICIENCES,  A-E 

LIABILITY  (III. 9) 

The  actual  handling  of  these  actions  is  determined  at 
the  local  level.  Boards  are  often  convened  to  make  determi¬ 
nations.  In  this  case,  the  modules  used  to  establish  board 
members  can  again  be  utilized.  Also,  some  reports  may  be 
necessary  in  certain  circumstances.  These  reports  can  be 
maintained  in  the  reports/letters  file.  All  matters 
concerning  disputes,  errors  and  omissions,  design  defici- 
ences,  etc.  require  correspondence.  A  word  processor  can  be 
used  to  produce  these  documents.  Copies  of  any  documents 
should  be  placed  in  the  contract  file. 

J.  FINAL  PAYMENT  (III. 10) 

The  final  payment  request  is  handled  in  the  same  manner 
as  the  progress  payments  except  the  contract  must  be  checked 
to  ensure  that  all  requirements  have  been  met.  The  same 
spreadsheet  database  is  used  in  this  process. 

K.  CCNTRACTOR  RELEASE  (III.  11) 

The  tracking  system  is  used  to  ensure  that  all  required 
submissions  have  been  made.  The  lead  engineer  mast  also 
provide  his  approval.  The  document  form  is  maintained  in  the 
reports/letters  file  for  the  contractor  release.  A  copy  of 
the  release  form  is  placed  in  the  contract  file. 


II.  END-USER  INTERFACE 


A.  EHD-USEE  PERCEPTICHS 

The  A-E  contract  MIS  described  in  the  previous  three 
chapters  is  intended  to  aid  the  contracting  officer  ar.d  the 
CS  in  managing  and  administering  the  A-E  contracting 
process.  The  end-users  of  the  system,  the  contracting 

officer  and  his  staff,  perceive  automated  systems  and  the 
use  of  computers  in  different  frames  of  reference.  The 
contracting  officer,  in  previous  tours  or  through  ferial 
schooling,  has  possibly  been  exposed  to  the  use  of  computers 
and  possibly  programming.  The  staff  members  may  or  may  rot 
have  ever  used  a  computer.  The  computer  to  them  may  be 

perceived  to  be  a  threat  to  their  jobs  or  a  new  method  and 

style  cf  work.  Therefore,  there  may  be  resistance  to  the 

change  from  a  fully  manual  process  to  one  in  which  the 
computer  is  an  integral  part. 

Users  judge  and  accept  a  system  on  the  basis  of  their 
personal  experience  with  it.  If  the  system  is  easy  to  learn 
and  use  then  it  is  normally  accepted  and  becomes  a  useful 
tool.  On  the  other  hand,  if  the  system  is  threatening  and 
difficult  to  use  they  will  probably  not  use  it.  This  can 
cause  extreme  problems  if  the  previous  methods  of  performing 
the  work  tasks  are  being  replaced  with  the  automated 
process.  Larson  [Ref.  9:  p . 2  ]  identifies  the  following 
factors  as  affecting  the  end-user's  perception  of  a  computer 
system: 

Time.  How  long  dees  it  take  the  end  user  to  perform  his 
task? 

Learning.  How  long  does  it  take  a  novice  to  learr.  the 
system? 


Recall.  How  easy  is  it  for  an  end  user  to  recall  hew  to 
use  the  system  after  he  has  not  used  it  for  some  time? 

Versatility.  Can  the  system  be  used  to  perform  a 
variety  of  tasks  that  the  end  user  faces? 

Errors.  How  many  errors  does  the  end  user  make  and  how 
serious  are  they? 

Help.  Does  the  system  provide  help  when  the  end  user 
has  trouble? 

Adaptability.  Does  the  system  adjust  to  the  end  user's 
level  of  competence  as  he  becomes  more  experienced? 
Does  the  system  tailor  itself  to  the  habits  and  styles 
cf  different  users? 

Concentration.  Hew  many  things  must  an  end  user  keep  in 
mind  while  using  the  system? 

Fatigue.  How  guickly  does  the  user  tire  while  using  the 
system? 

Dnif or mi tv .  Are  the  commands  of  this  systeE  identical 

to  equivalent  commands  of  other  systems? 

Fun.  Does  the  end  user  enjoy  the  system? 

Chapters  6-8  described  various  automated  tools  which  can  be 
used  in  the  three  phases  of  the  A-E  contracting  process.  The 
design  and  development  of  these  tools  could  be  excellent  tut 
if  the  end-user  has  difficulty  in  understanding  or  using  the 
tools  they  are  useless.  End-user  interfaces  must  be  designed 
into  the  system  to  ensure  the  above  factors  are  satisfied. 
Failure  to  satisfy  them  can  result  in  the  users  not  using 
the  system  or  not  gaining  the  full  benefits  from  the  use  of 
the  system. 

E.  SCREEN  DESIGNS 

The  A-E  contracting  MIS  must  be  designed  to  permit  the  user 
to  perform  the  contracting  process  tasks  in  a  smooth  manner. 
A  major  element  in  achieving  this  is  the  structure  of  the 


system  and  how  it  is  configured.  This  will  be  described  in 
the  following  chapter.  The  second  element  to  this  achieve¬ 
ment  is  the  design  of  the  methods  by  which  the  user  is 
"guided"  through  the  system.  These  methods  include  the  use 
of  menus,  prompts,  information  presentation,  data  presenta¬ 
tion,  text  presentation,  messages  and  replies,  and  help 
facilities  [Ref.  10:  pp.  1 9-2 1, 34, 36-37  ]. 

1 .  Menus 


Menus  present  the  user  with  a  number  of  choices,  the  user 

keys  in  his  choice  and  the  system  moves  on.  Menus  can 

present  any  number  of  choices,  however  as  the  number 

increases  so  does  the  confusion  of  the  user.  Menu  options 
should  be  limited  to  as  small  a  number  as  possible.  As  an 
example  consider  the  main  menu  used  in  the  Contractor 


A) 

MAIN  MENU 

Add  a  record 

D) 

Delete  a  record 

E) 

•  Exit  (  work  completed  ) 

H) 

Help 

P) 

Print  a  report 

Q) 

make  a  Query 

U) 

Update  a  record 

V) 

View  a  record 

Choose  an  option:  _ 

Figure  9.1  Contractor  Information  System  Main  Menu. 


Information  System,  Figure  9.1.  This  menu  offers  the  user  a 
selection  of  all  the  possible  options  and  features  available 


under  the  CIS  application  module.  The  user  knows  by  the 
names  used  for  the  options  what  can  be  performed  by  using 
this  module.  The  options  are  listed  in  alphabetical  order 
where  the  option  selection  keys,  (A,  D,  E,  H,  P,  Q,  U,  and 
V)  ,  correspond  to  the  key  word  of  the  option.  If  mere  than 
nine  options  are  necessary,  it  is  better  to  divide  the  menu 
into  two  separate  menus,  chaining  them  together. 

2 .  Prompts 

Prompts  are  text  on  the  screen  identifying  the  type 
of  information  that  the  system  desires  the  user  to  enter.  In 
simple  terms,  they  are  just  questions  and  answers.  At  the 
conclusion  of  entering  a  new  record  into  the  CIS  database 
the  user  is  ask,  "DO  YOU  WANT  TO  INPOT  ANOTHER  RECORD?  (Y  OR 
N)".  The  system  waits  for  a  response  from  the  user  before 
any  other  action  takes  place. 

Prompts  can  also  take  the  form  of  screen  overlays 
which  show  the  format  for  the  entry  of  data.  Figure  9.2  is 
the  data  entry  format  used  to  add  records  to  the  CIS  data¬ 
base.  In  this  approach,  the  cursor  appears  at  the  first 
entry  point.  Contractor  Number,  for  the  entry  of  the  first 
data.  Only  four  digits  are  permitted  for  the  contractor 
number.  This  limitation  is  shown  by  the  number  of  blank 
spaces  in  the  prompt.  Rather  than  using  blanks,  reverse 
video  highlights  the  entry  areas  and  limitation  on  the  allo¬ 
wable  data  entry  field  length.  Reverse  video  is  not  provided 
on  all  terminals.  After  the  user  has  entered  the  first  data, 
the  cursor  jumps  to  the  next  data  entry  area.  Phone.  The 
user  can  move  back  to  a  previous  data  entry  area  tc  change 
data  if  reguired.  Methods  for  this  movement  between  data 
areas  is  dependent  upon  the  hardware  utilized.  The  cursor 
continues  to  move  to  the  next  data  entry  area  until  all  the 
data  has  been  entered  for  this  screen.  The  CIS  requires  two 
screens  to  input  all  the  contractor  information.  Ihe 


Fee  for  project  3 


completion  of  the  last  data  item.  Fee  for  project  3,  will 
automatically  call  the  next  screen  up  for  the  user  to 
complete.  If  any  data  item  is  not  known  or  not  applicable, 
the  entry  area  can  be  skipped  by  pressing  the  return  key. 

The  entry  screens  should  call  for  the  information  as 
it  appears  on  the  source  documents.  This  will  permit  the 
user  to  go  through  the  source  document  smoothly  rather  than 
jumping  randomly  over  it.  Crowding  too  much  on  one  screen 
makes  the  entry  process  difficult.  There  should  be  space 
between  each  data  entry  area. 


CONTRACTOR  DATA  FILE 

Contractor  Number  - _  Phone  -  ( _ )- 

Contractor  Name  - 


Street  or  P.O.Box  - 


City  - _  State  - _ Zip 

-  PROJECT  HISTORY  - 

Project  1  -  _ 

Project-!”- _ _ _ _ 

F  €  €  —  ~ 

Project-!- =~ 

Fee  -  - 


Figure  9.2  Data  Entry  Screen  for  CIS. 


3*  Inf orma tion  Presentation 

Information  presented  to  the  user  should  be  in  a 
usable  form.  For  example,  the  tracking  systems  for  all  the 
contracting  phases  require  the  entry  of  several  dates  by  the 
user.  The  dates  should  always  be  asked  for  by  the  system  in 
a  form  that  is  normally  used  by  the  user  (i.e.  DD/MF/YY, 


MM/DD/Y  Y  or  even  May  18,  1984).  These  forms  are  cons  on  to 

everyday  use.  While  these  forms  are  easiest  for  the  user, 
the  julian  date  system  is  more  practical  for  use  in  computa¬ 
tions  undertaken  by  the  computer.  The  input  from  the  user 
in  one  cf  the  above  forms  can  be  easily  converted  to  a 
julian  date  by  the  computer.  Likewise  the  output  or  presen¬ 
tation  of  the  information  to  the  user  should  be  in  a 
normally  acceptable  form.  The  computer  should  convert  any 
internal  data  format  to  a  readable  format  for  the  user.  The 
user  should  never  have  to  rely  on  a  coding  scheme  to 
decipher  information  presented  by  the  computer  for  his  use. 

4 «  Cata  Presentation 

Data  presentation  concerns  the  display  of  non-native 
language  information  on  the  screen.  Most  of  the  information 
presented  in  the  proposed  A-E  MIS  is  in  a  readable  form. 
There  could  be  applications  which  would  list  cost  data  along 
with  cost  category  codes  or  contractor  numbers.  The  data 
should  be  identified  by  titles  or  headings  of  sore  sort. 
Displays  such  as  47528052347654,  where  4752  is  the 
contractor  number  and  (805) -234-7654  is  the  contractors 
phone  number,  make  no  sense  to  the  normal  user.  An  example 
of  acceptable  data  presentation  is  the  Contractor  Discipline 
Profile  screen  shown  in  Figure  9.3.  The  main  body  of  the 
screen  displays  the  discipline  codes  and  the  number  of 
personnel  are  in  the  discipline  category.  The  discipline 
codes  are  numeric  as  are  the  count  of  personnel  in  the 
categories.  Each  code  and  count  number  are  separated  and  the 

definition  of  the  code  is  listed  (i.e.  10  _ 25  Civil  Eng 

indicating  there  are  25  persons  in  discipline  category  10 
which  is  Civil  Engineers). 
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CONTRACTOR  DISCIPLINE  PROFILE 

Contractor 

Contractor 

Number  - 
Name  - 

Discipline 

Code  -  Number  of 

Personnel 

0  1  24 

A  dministrative 

02 

20 

Electrical  Eng 

0  3  ““ 

Oceano  qrahers 

04 

— 10 

Architect 

05 - 

Estimators 

06 

Urban  Planners 

07 - 

Chemical  Eng 

08 

Geolo  qis  ts 

09  3 

Sanitary  Ena 

10 

“25 

Civil  Eng 

1  1 - 

Hy droloqists 

12 

Soils  Enq 

13 

Construct  Insptr 

14 

Inter.  Design 

1 5 

Spec  Writer 

16 

- 12 

Draftsman 

17 - if 

Landscape  Arch 

18 

Structural  Enq 

19 

Ecologists 

20 

“  3 

Mechanical  Eng 

2 1  “TO 

Surveyors 

22 

Economists 

23  ““ 

2  5 - 

Mining  Eng 
General 

24 

— 

Transport  Eng 

— >  DC  YOU 

WANT  TC  INPUT  ANOTHER 

RECORD 

?  (  Y  or  N  ) 

Figure  9.3  CIS  Contractor  Discipline  Profile  Screen. 

5 •  Text  Presentation 

It  is  often  necessary  to  give  instructions  or 
present  information  in  the  form  of  text.  For  reading  ease, 
the  text  should  be  in  upper  and  lower  case.  The  text  should 
be  presented  in  short  sentences,  allowing  enough  space 
between  paragraphs  sc  as  not  to  crowd  the  screen.  If  neces¬ 
sary,  use  more  than  one  screen  to  display  the  information 
rather  than  crowd  toe  much  on  one  screen.  Figure  9.4  illus¬ 
trates  these  concepts.  The  instructions  appear  in  the 
module  used  to  view  contractor  data.  The  instructions  are 
brief  and  to  the  point.  Since  there  is  more  information  than 
can  be  presented  on  one  screen,  two  screens  are  used.  The 
user  can  scroll  to  the  second  screen  by  simply  hitting  any 
key.  The  browsing  instructions  given  on  the  second  screen 
also  appear  on  the  data  screens  in  an  abbreviated  form. 
Simplicity  and  under standability  are  the  key  elements  to  be 
followed . 
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♦♦SCREEN  I** 

To  view  a  specific  contractor's  data  record  you  need 
to  know  the  contractor  number. 

If  a  specific  number  is  not  used  you  will  begin  with 
the  first  record.  The  records  are  arranged  in 
alphabetical  order  by  contractor  name. 

You  can  also  just  browse  thru  the  records. 


PRESS  ANY  KEY  TO  CONTINUE 


♦♦SCREEN  2** 


The  following  options  are  available  in  browse: 

B) ack--Takes  you  to  the  previous  record. 
Fiorward — Takes  you  to  the  next  record. 


Fiorward — Takes  you  to  the  next  record. 

P)  rofile — Displays  the  Discipline  Profile. 

of  the  contractor. 

N) umber — Permits  you  to  locate  a  contractor 
by  the  contractor  number. 

Q)  uit — Returns  vou  to  the  main  menu. 


Do  you  need  to  see  a  listing  of  the  contractor  numbers? 


Figure  9.4  Text  Presentation  in  the  CIS  Module. 


6.  Messages  and  Replies 

Communications  that  emanate  from  the  computer  to  the 
user  form  a  direct  psychological  link  between  the  user  and 
the  computer.  These  communica tions  give  the  computer  some 
human-like  qualities  that  tend  to  be  perceived  to  threaten 
the  user.  Like  conversing  with  an  individual,  the  computer 
should  never  produce  a  blank  screen.  This  lack  of  feedback 
often  gives  the  user  a  feeling  of  being  lost.  If  a  process 
is  being  carried  out  which  requires  more  than  3  seconds,  it 
is  best  to  provide  a  message  to  the  user  that  a  process  is 
taking  place.  In  the  CIS  module,  the  initialization  of 
memory  variables  requires  approximately  10  seconds.  During 


this  time,  the  user  is  presented  with  a  sign-on  screen 
display  as  shown  in  Figure  9.5.  The  display  of  the  screen 
does  not  make  the  initialization  process  go  any  faster,  rut 
the  user  is  told  of  the  time  requirement  and  exactly  what  is 
going  cn. 


NAVFACENGCOM 

Contractor  Information  System 


A  Micro-Processor  Application 
of 

FACSO's  CIS 


Developed  by: 

TOM  ETHERIDGE 

SPRING  QUARTER  1984 
NAVAI  POSTGRADUATE  SCHOOL 

Wait  10  seconds  for  system  initialization  to  complete. 
- >  Press  any  key  to  continue  < - 


Figure  9.5  CIS  Sign-on  Screen  Display. 

The  most  valuable  messages  in  terms  of  system 
control  and  protection  are  error  messages.  They  inform  the 
user  of  mistakes  or  the  failure  to  comply  with  system 
imposed  constraints  such  as  data  formats.  Error  messages 
should  be  concise  and  yet  provide  enough  information  for  the 
user  to  recover  from  an  error.  Verbosity  and  error  messages 
do  not  go  together.  When  possible,  the  error  message  should 
permit  an  escape  for  the  user.  Figure  9.6  is  an  example  of 
an  error  message  used  in  the  delete  module  of  the  CIS.  This 
message  appears  when  the  user  requests  to  ielete  a 
contractor  record  that  does  not  exist  in  the  file.  The  user 
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is  told  that  the  contractor  record  does  not  exist.  Then  the 
user  is  given  an  option  or  an  escape.  The  user  is  not  left 
wondering  what  should  be  done. 


That  contractor  number  is  not  in  the  file. 


Do  you  want  to: 

1)  Try  again  or, 

2)  Return  to  main  menu. 


Figure  9.6  Sample  Error  Message. 


7 -  Help  Facilities 

On-line  help  facilities  are  an  advantage  if  they  can 
provide  information  for  the  user  in  a  capsulated  form.  If 
extensive  helps  are  required  they  should  be  provided  in  the 
user’s  manual.  Concise  helps  or  memory  aids  can  save  the 
user  the  effort  of  having  to  continuously  go  to  the  refer¬ 
ence  material.  For  a  large  diverse  system  it  is  best  to 
design  the  help  facilities  such  that  they  reside  in  the 
modules  in  which  they  are  needed  rather  than  in  one  large 
separate  module.  A  menu  of  help  information  should  be 
presented  where  the  user  can  choose  the  desired  help. 

C.  INTERFACE  TRADE-OFFS 


All  the  interfaces  described  in  the  above  paragraphs  are 
included  in  the  system  to  improve  the  "friendliness"  of  the 
system.  These  aids  to  system  use  require  storage  space  in 


memory  as  do  the  application  modules  and  data.  There  has  to 
be  a  limit  to  the  aids  provided  in  order  to  balance  the 
storage  reguirements.  Consideration  must  be  given  tc  the 
number  of  help  facilities  and  the  amount  of  information 
contained  in  each.  The  other  trade-off  to  be  considered  is 
the  time  response  cf  the  system  when  a  large  number  of 
interface  aids  are  provided.  These  problems  of  storage  are 
being  overcome  by  the  current  advances  in  storage 
technologies. 


X.  SYSTEM  INTEGRATION 


Chapters  6  through  3  presented  a  proposal  for  an  auto¬ 
mated  approach  to  the  management  of  the  A-E  contracting 
process.  The  last  chapter  stressed  the  importance  of  the 
interface  between  the  user  and  the  automated  system.  This 
chapter  will  present  the  system  components  in  a  MIS  frame¬ 
work  and  explore  the  hardware  and  software  aspects  to  be 
considered  for  i npleientation  of  the  MIS. 

A.  OVERVIEW 

In  Chapter  5,  a  MIS  framework  was  described  as  an  inte¬ 
grated  system  for  providing  planning,  operation,  and  control 
of  a  management  function.  The  proposed  A-E  automated 
tracking  and  management  system  presented  earlier  fits  best 
into  this  framework  as  shown  in  Figure  10.1.  The  functions 
of  the  databases,  reports/letter  file,  contract  files,  and 
application  programs  are  integrated  to  form  the  A-E  MIS. 
The  user  accesses  the  MIS  through  the  use  of  a  workstation 
equipped  with  a  keyboard  for  data  entry,  a  CRT  for  viewing 
system  responses  and  dialogue  screens,  and  a  printer 
utilized  to  produce  hardcopy  printouts  of  reports,  letters, 
and  schedules.  The  user  interacts  with  the  MIS  at  the 
highest  level  through  the  supervisory  program.  This 
program,  through  menus  and  user  friendly  prompts,  permits 
the  user  to  select  cne  of  the  functions  or  applications1 
available  for  use.  After  a  selecting  of  one  of  the  func¬ 
tions,  control  of  the  MIS  shifts  to  that  function,  meaning 
that  the  user  interacts  directly  with  the  function.  This 


1 A  complete  listing  of  the  application 
reports/letters  file,  contract  files,  and  databases 
for  the  A-E  MIS  can  be  found  in  Appendix  B. 


programs, 

proposed 


w 
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level  cf  control  is  below  that  of  the  supervisory  progran  in 
a  manner  that  when  the  user  completes  the  use  of  the 
selected  function,  control  always  reverts  back  to  the  super¬ 
visory  program.  Application  programs  normally  consist  of 
several  modules  much  like  the  CIS  application  program  listed 
in  Appendix  A.  During  execution  of  an  application,  control 
may  be  passed  to  any  cf  the  modules.  But,  just  as  with  the 
supervisory  program,  when  the  modules*  process  is  complete, 
control  returns  to  the  main  module  of  the  application. 

Once  the  user  has  access  to  a  particular  application, 
other  functions  of  the  HIS  come  into  play.  The  application 
program  may  call  or  access  one  of  the  databases,  a  form 
report/letter  from  the  reports/letters  file,  a  contract  file 


88 


or  any  combination  of  these  functions.  As  mentioned  above, 
when  the  user  is  finished  with  the  application  or  function, 
control  returns  back  to  the  supervisory  program  where  the 
user  can  activate  another  application  or  simply  leave  the 
system. 

B.  DATA  DICTIONARY 

A  subsystem  not  shown  in  Figure  10. 1  but  which  plays  an 
important  role  in  the  useability  of  the  MIS  is  the  data 
dictionary.  The  data  dictionary  is  documentation  of  the  data 
items  included  in  the  databases  together  with  their  rela¬ 
tionships  with  other  data  and  programs  or  routines  that  use 
them.  The  major  purpose  of  the  data  dictionary  is  to  aid  in 
the  consistency  of  the  MIS  data.  It  normally  contains  data 
field  definitions  (how  many  spaces  are  permitted  for  a  data 
element),  data  definitions  (what  is  and  is  not  included  in 
the  data  element),  and  comment  information  to  explain  any 
ambiguities  in  the  data  elements.  Data  dictionaries  can 
contain  explanations  cf  any  restrictions  on  data,  enforce¬ 
ment  measures  utilized  by  the  database  (error  checking  for 
data  entry) ,  or  modules  for  monitoring  the  usage  of  data. 
The  data  dictionary  can  be  either  in  hardcopy  form  such  as 
[Bef.  6],  or  be  available  on-line.  In  most  cases,  it  is  best 
to  have  hardcopy  documentation  of  the  data  dictionary  with 
an  abbreviated  form  available  on-line  since  microcomputer 
systems  normally  have  limited  storage  capability.  This 
constraint  will  vary  from  system  to  system  and  will  become 
less  and  less  a  constraint  as  storage  technology  advances. 

C.  I BPIEHENTATION  OF  THE  MIS 

The  concepts  proposed  in  the  previous  chapters  have  been 
based  on  the  idea  that  the  field  activities  need  the  ability 
to  manage  and  control  their  functional  responsibilities 
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through  the  use  of  existing  computer  technologies.  The  hard¬ 
ware  and  software  required  to  implement  the  proposed  A-E 
MIS,  as  well  as  any  ether  small  activity  management  systems, 
currently  exists  on  the  commercial  market.  The  A-E  MTS  is 
suitable  for  operation  on  most  business  microcomputers  being 
used  today.  The  micr ccomputer  has  several  advantages  over  a 
larger  system  for  this  application,  of  which  the  first  is 
cost.  Mcst  micro-based  systems  can  be  purchased  for  less 
than  $5,000  and  many  less  than  $3,000.  The  second  is  that 
technologically  better  computers  are  produced  at  a  lower 
cost  while  at  the  same  time  the  amount  of  storage  capacity 
built  in  them  drastically  increases.  The  standard  business 
micro-computer  in  1983  had  192K  to  256K  of  internal  memory 
with  normally  dual  300K  to  400K  floppy  disk  drives  providing 
the  user  with  600K  tc  800K  of  easily  accessed  memory.  In 
1984,  micro-computers  are  equipped  with  the  same  amount  of 
internal  memory  but  with  a  greater  than  tenfold  increase  in 
storage  memory  of  10  Megabytes.  In  1985,  micro-  computers 
are  projected  to  provide  512K  of  internal  memory  and 
possibly  205  Megabytes  of  storage  memory.  In  the  next  few 
years,  it  is  projected  that  read  only  laser  disk  storage 
providing  up  to  4  gigabytes  of  read  only  storage  will  be 
available.  All  the  storage  memory  devices  will  be  located 
within  the  actual  micro-computer  frame.  Existing  microcom¬ 
puter  can  be  upgraded  to  take  advantage  of  the  advances  in 
storage  memory.  A  third  advantage  of  the  micro-  computer  is 
its  ability  to  be  easily  adapted  to  the  organizational 
management  style.  The  size  and  cost  of  the  micro-  computer 
permits  management  to  place  the  computing  power  on  the  desk 
of  those  who  need  it. 

Commercial  software  products  are  available  which  provide 
the  facilities  necessary  to  implement  the  proposed  A-E  MIS. 
These  application  products  can  also  be  used  by  the  aggres¬ 
sive  manager  to  develop  personal  management  tools  as  well  as 


expand  on  those  proposed  herein.  The  ease  of  use  and  the 
high  level  orientation  of  these  products  make  the  need  for 
systems  programmers  obsolete  for  the  development  of  simpler 
applications. 

The  CIS  programs  listed  in  Appendix  A  were  developed  on 
a  Zenith  Z-1002  through  the  use  of  two  compatible  software 
products,  dBASE  II5  and  ’WordStar'.4  dBASE  II  is  a  database 
management  tool  that  allows  easy  manipulation  of  small  and 
medium  sized  databases  using  English-like  commands.  WordStar 
is  a  word  processing  program.  These  two  application  pack¬ 
ages  could  be  used  to  develop  the  entire  A-E  MIS.  ether 
software  packages  could  be  used  but  these  two  are  completely 
compatible  taking  a  major  effort  of  internal  system  inter¬ 
facing  out  of  the  design  effort.  The  systems  should  also 
work  on  any  IBM  compatible  and  a  large  variety  of  CP/M5 
systems. 


2Zenith  Z-100  is  a  registered  trademark  of  Zenith  Data 
Systems. 

3dEASE  II  is  a  registered  trademark  of  Ashton-Tate. 

♦WordStar  is  a  registered  trademark  of  MicroPro 
International. 

5CP/M  is  a  registered  trademark  of  Digital  Research. 


XI.  CONCIDSIONS  AND  RECOMMENDATIONS 


A.  CCHCIOSIOHS 

For  NAVFAC  to  effectively  carry  oat  their  mission  effec¬ 
tives,  enormous  amounts  of  data  are  required  to  be 
collected,  organized  into  logical  informational  forms,  and 
analyzed.  Hell  developed  information  management  systems  are 
used  to  make  this  possible.  The  systems  utilize!  are 
reviewed  annually  to  ensure  that  they  adequately  support  the 
mission.  Systems  enhancements  are  developed  and  installed  to 
farther  the  inclusion  of  improved  technological  advances. 

The  majority  of  the  computing  power  used  by  the  NAVFAC 
Naval  Facilities  System  is  centrally  located  in  Port 
Hueneme,  Ca.  at  FACSO.  The  data  from  field  activities  is 
collected  at  decentralized  sites  (EFDs)  and  forwarded  to  the 
central  site  (FACSO) .  The  reports  utilized  for  management  of 
NAVFAC  functions  are  distributed  in  hardcopy  form  to  the 
field  activities.  The  major  decisions  concerning  planning 
and  requirements  definition  for  the  Naval  Facilities  System 
Plan  is  centralized  at  NAVFAC  Headquarters.  The  execution 
and  implementation  of  the  plans  is  centralized  at  FACSO. 

The  current  objective  of  the  Naval  Facilities  System  is 
to  depart  from  the  wholly  centralized  approach  of  data 
processing  and  to  decentralize  some  system  functions 
[Ref.  1:  p.5-1  ].  The  initial  decentralization  is  focused  at 
the  EFDs,  Public  Works  Centers  and  larger  Public  Works 
Departments.  This  is  a  decentralization  of  hardware  and 
software  but  not  systems  development.  Development  of  major 
systems  is  to  remain  at  FACSO  and  planning  for  NAVFAC-wide 
systems  will  remain  at  NAVFAC  Headquarters.  The 
decentralized  sites  will  be  able  to  develop  local  systems 
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and  applications  which  can  effectively  improve  procedures 
and  management.  This  decentralization  is  slowly  evolving 
down  to  the  field  activity  level.  Some  applications  have 
keen  developed  to  support  field  activities,  however  most  are 
presently  geared  toward  collecting  and  submitting  data  in 
support  of  the  major  NAVFAC  data  processing  systems. 

Several  management  processes  exercised  at  the  field 
activity  level  could  be  improved  and  modernized  by  the 
development  of  automated  data  processing  applications.  The 
A-E  contracting  management  process  is  just  one  of  these 
processes.  Develop  cf  applications  as  described  in  Chapters 
6-8  is  possible  as  evidenced  by  the  development  of  the 
Contractor  Information  System  shown  in  Appendix  A. 

Current  micro-computer  technology  will  support  the  auto¬ 
mation  requirements  cf  field  activities  since  advances  have 
greatly  increased  the  secondary  storage  capacity  cf  these 
machines.  Many  application  building  tools  such  as  word 
processing,  database,  and  electronic  spreadsheets  software 
are  available  for  development*  of  management  systems.  These 
tools  are  at  the  level  that  the  aggressive  manager  can 
develop  local  applications  to  improve  his  own  management 
techniques  and  performance.  Micro-computers  can  easily  be 
adapted  for  transmission  of  data  to  other  computers  as  well 
as  integrated  into  local  area  networks  where  several  micro¬ 
computer  can  share  applications  and  computing  power.  The 
cost/benefit/performance  considerations  of  micro-computers 
make  them  excellent  tcols. 

E.  BICOMMISDATIOHS 

The  main  theme  cf  the  recommendations  to  be  made  is  to 
take  a  unified  planning  approach  in  evaluating  data 
processing  for  field  activities.  The  recommendations  are  as 
follows: 


1.  A  centralized  abroach  should  be  taken  to  identify  the 
key  needs  of  the  field  activities  in  the  area  of  data 
processing.  Orly  those  functions  which  are  of  benefit 
to  the  majority  of  the  activities  should  be  pursued. 
Fossibly  subgroups  can  be  identified  for  secondary 
consideration  by  those  activities  affected. 

2.  A  centralized  evaluation  and  selection  of  available 
software  (word  processors,  database  managers,  and 
electronic  spreadsheets)  should  be  made  to  reduce  the 
cause  of  inconsistent  applications  development.  The 
number  of  permitted  software  products  snould  be  kept  to 
a  minimum  while  at  the  same  time  permit  enough 
diversification  to  avoid  dependence  on  one  vender  or 
system . 

3.  Similar  to  2  above,  a  centralized  evaluation  should  be 
made  of  available  micro-computers.  Limiting  the 
selection  to  not  only  operating  systems  [Ref.  11],  hut 
alsc  to  vendors  would  a _  air.  aid  in  r-ducing  :..e 
proliferation  of  hardware. 

4.  Establish  field  activity  user  groups  ere 

communications  can  begin  for  the  purpose  or  sharia  ; 
ideas,  problem  solutions,  and  applications.  Due  to  the 
large  geographic  dispersion  of  the  activities,  central 
centers  for  information  exchange  should  be  .identified 
(newsletters,  regional  periodic  meetings,  software 

exchanges) . 

5.  An  aggressive  approach  toward  the  integration  of  the 
field  activity  systems  into  the  NFS  will  take  advantage 
of  current  technology.  The  increased  sophistication  of 
small  computer  systems  and  the  advances  of 
communications  software  bring  these  two  functions 
closer  together. 

6.  Incorporate  a  total  system  approach  to  systems 
development  to  merge  the  areas  of  office  automation. 
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APPENDIX  A 
SAMPLE  APPLICATION 


CONTRACTOR  INFORMATION  SYSTEM 
-  A  dBASE  II  PROGRAM  - 


The  dEASE  II  ccirniand  language  has  been  used  to  implement  a 
contractor  information  system  used  by  Naval  Facilities 
Engineering  Command-  The  system  has  been  designed  under  the 
following  assumptions: 

a)  Users  of  the  systems  are  inexperienced  in  computer 
usage. 

b)  The  system  should  permit  facilities  tc  add,  delete 
and  browse  thru  the  data.  It  should  also  permit  any 
persons  knowledgeable  with  dBASE  II  to  use  the 
query  language  on  the  database.  (  This  is  made 
only  under  the  premise  that  the  system  will  be 
used  by  a  small  group  (  3-4  persons) .  It  should 
also  be  oointed  that  by  having  access  to  the 
database* that  a  person  can  change  the  database  by 
deleting  records  or  modifying  existing  data. 

c)  The  system  is  used  by  a  small  group  of  people. 

d)  The  database  should  as  much  as  possible  be 
designed  to  match  the  database  structure  of  the 
existing  NAYFAC  database.  This  will  make  future 
interfacing  with  easier. 

Two  files  are  maintained.  The  contractor  data  file  (caata) 
and  the  contractor  discipline  file  (edis) .  The  cdata.dbf  contains 
basic  demographic  information  plus  a  short  history  of  the 
contractor’s  work  for  the  USN.  The  cdis.dbf  contains  a'breakdown 
of  the  composition  of  the  contractor’s  engineering  workforce. 
This  data  is  taken  from  the  SF  254  and  SF  255.  These  forms  are 
the  D.S.  Governments  contractor  resume  forms.  The  information  is 
maintained  for  future  Invitation  For  3id  mailing  lists  and  also 
for  a  reference  for  the  Public  Works  Officer  to  consult  when  he 
needs  a  rapid  response  design  to  solve  an  emergent  problem. 

The  file  structures  for  the  two  dbfs  are  given  below.  A 
brief  data  dictionary  is  also  given  to  aid  in  defining  the  fields 
and  data  elements. 

STRUCTURE  FCR  FILE:  CDATA.DBF 
NUMBER  OF  RECORDS:  C0010 

CATE  CF  LAST  UPDATE:  06/12/84 
PRIMARY  USE  DATABASE 


FLD 

NAME 

TYPE 

WIDTH 

001 

CNUM1 

C 

004 

002 

CNAME1 

c 

036 

003 

CNAME2 

c 

036 

004 

STPOB 

c 

040 

005 

CITY 

c 

021 

006 

STATE 

c 

002 

007 

ZIP 

c 

005 

008 

EHCNE 

c 

014 

009 

FROJ1 

c 

050 

010 

E2E1 

C 

006 

011 

FEOJ2 

C 

050 

012 

FEE2 

c 

006 

013 

FROJ3 

c 

050 

014 

FEE3 

c 

006 

015 

DELETED 

c 

007 

** 

TOTAL  ** 

00334 

CDATA  Data  Dictionary 

Field 

1 

2 

3 

4 

c 

6 

7 

8 

9 


10 


11 

12 

13 

14 

15 


CNUM1  Contractor  number  assigned  automaticallv  tv  the 
system.  4  alphanumeric  spaces  are  permitted. 

CNAME1  Contractor  name,  first  line.  36  alpha  characters 
are  permitted. 

CNAME2  Contractor  name,  second  line.  36  alpha  characters 
are  permitted. 

STPOF  Street  address  or  the  post  office  box.  40 
alphanumeric  characters  permitted. 

CITY  City  cf  the  address.  21  alpha  characters  are 
permitted. 

STATE  State  of  the  address,  2  letter  aboreviations.  2 
alpha  charcaters  are  permitted. 

ZIP  Zip  cede  associated  with  the  address.  5 

alphanumeric  characters  are  permitted. 

PHCNE  Telephone  number  of  the  contractor  including  the 
area  code.  14  alphanumeric  characters  are 
permitted. 

PROJ1  Brief  description  of  the  latest  project  completed 
by  the  contractor  for  the  government.  50  alpha 
characters  are  permitted. 

FEE  1  The  fee  in  thousands  of  dollars  paid  tc  the 

contractor  for  the  projected  completed  above. 

6  alphanumeric  characters  are  permitted. 

PROJ2  Same  as  PRO J 1  except  for  second  project. 

FEE2  Same  as  FEE1  except  represents  PROJ2. 

PRO J3  See  above. 

FEE3  See  above. 

DELETED  Field  used  to  indicate  that  a  record  has  teen 

identified  for  deletion.  7  alpha  characters  are 
permitted. 


The  edata  file  is  indexed  to  the  file  NAMES.  NDX  by  the  contractor 
names.  A  sample  of  the  data  in  the  edata. dbf: 

00001  1234  HE SCOTT  BROTHERS  DESIGN  AND  ESTIMATE 

00002  2345  JOHNSON  AND  JOHNSON  ASSOC.  INC. 

00003  3456  ABC  ENGINEERING 

00004  4567  FIRST  RATE  GUYS  WITH  A  SLIDE  RULE 

00005  5678  ONE  MAN  ENGINNER ING  COMPANY 

00006  6787  KEPLER  FRANK  AND  WESPEPPER 

00007  8765  ZEDE  PLUMBING  AND  HEATING 

00008  9065  BROWN  AND  ROOT 

00009  7303  DIEBOLD  PIPE  AND  SIEEL  ENGINEERS 

00010  4532  WERE  YOU  THERE 


The  CDIS  dbf: 


STRUCTURE  FCE  FILE: 

CDIS 

.DBF 

NUMBER 

OF  RECORDS: 

C0010 

DATE  CF 

LAST  UPDATE: 

06/12/84 

SECONDARY  USE  DATABASE 

FLD 

NAME 

TYPE 

WIDTH 

001 

CNUM2 

C 

004 

002 

NAD 

C 

004 

003 

NEE 

C 

004 

004 

NOG 

C 

004 

005 

NA 

C 

004 

006 

NEST 

C 

004 

007 

NOP 

C 

004 

008 

NCHE 

C 

004 

009 

NGE 

C 

004 

010 

NSNE 

C 

004 

011 

NCE 

C 

004 

012 

NH7 

C 

004 

013 

NSOE 

C 

004 

014 

NCI 

C 

004 

015 

NID 

C 

004 

016 

NS  PS 

c 

004 

017 

NDMN 

c 

004 

018 

NLA 

c 

004 

019 

NSTE 

c 

004 

020 

NECO 

c 

004 

021 

NHE 

c 

004 

022 

NSOR 

c 

004 

023 

NECN 

c 

004 

024 

NMNE 

c 

004 

025 

NTRE 

c 

004 

026 

NGE 

c 

004 

027 

TOTEMP 

c 

006 

**  1 

ICIAL  ** 

00111 

- 

+-+- 

CDIS  Data  Dictionary 

Field 

1 

CN0M2 

Contractor  number  assigned  by  the  system 

2 

NAD 

This  is  the  same  number  as  CNUM1. 

4  alphanumeric  characters  are  permitted. 
Number  of  administrative  personnel. 

3 

NEE 

4  alphanumeric  characters  are  permitted. 
Number  of  electrical  engineers. 

4 

NOG 

4  alphanumeric  characters  are  permitted. 
Number  of  oceanographers. 

5 

NA 

4  alphanumeric  characters  are  permitted. 
Number  of  architects. 

6 

NEST 

4  alphanumeric  characters  are  permitted. 
Number  of  estimators. 

7 

NOP 

4  alphanumeric  characters  are  permitted. 
Number  of  urban  planners. 

4  alphanumeric  characters  are  permitted. 
Number  of  chemical  engineers. 

8 

NCHE 

9 

NGE 

4  alphanumeric  characters  are  permitted. 
Number  of  geologists. 

10 

NSNE 

4  alphanumeric  characters  are  permitted. 
Number  of  sanitary  engineers. 

11 

NCE 

4  alphanumeric  characters  are  permitted. 
Number  of  civil  engineers. 

12 

NHY 

4  alphanumeric  characters  are  permitted. 
Number  of  hydrologists. 

13 

NSCE 

4  alphanumeric  characters  are  permitted. 
Number  of  soil  engineers. 

14 

NCI 

4  alphanumeric  characters  are  permitted. 
Number  of  construction  inspectors. 

15 

NID 

4  alphanumeric  characters  are  permitted. 
Number  of  interior  designers. 

16 

NSPW 

4  alphanumeric  characters  are  permitted. 
Number  of  spec  writers. 

17 

NDHN 

4  alphanumeric  characters  are  permitted. 
Number  of  draftsmen. 

18 

NLA 

4  alphanumeric  characters  are  permitted. 
Number  of  landscape  architects. 

19 

NSTE 

4  alphanumeric  characters  are  permittel. 
Number  of  structural  engineers. 

20 

NECO 

4  alphanumeric  characters  are  permitted. 
Number  of  ecologists. 

+- 
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*ain  Command  Module 


******************************************************************* 


*  main.cmd  6/5/34  jte  * 

*  version:  1.0  * 

*  purpose:  sets  the  rain  selection  screen  and  permits  the  user  * 

*  to  select  which  option  they  would  like  to  operate  * 

*  from,  processina  narrative:  the  sian-on  is  dis. laved  * 


'  4.X.  vs  ill*  ^lUV/CCOXlij  uai.i.ui.4  VC.  V.  IIKZ  0  4.^  11  ll  X  O  413  ,  iaj  ca 

*  followed  by  the  initialization  of  the  system,  the  * 

*  main  selection  screen  is  then  presented,  all  * 

*  terminated  selection  return  the  user  to  the  main  menu.  * 

*  superordinate  modules:  none  * 

*  subordinate  modules:  sign-on. cmd,  init.cmd,  main.fmt,  add. cam,  * 

*  delete.cmd,  view.cmd  - 

*  author:  Tom  Etheridge  * 

*********************************************************  ********** 


♦display  sign-on  message 

EO  sign-cn 

SET  CONSOLE  OFF 

UAIT 

SET  CONSOLE  ON 

* 

♦initialize  variables  and  set  the  environment 
EO  init 
* 


♦set  up  the  main  loop 
DO  5HILE  t 
* 


♦set  up  screen 
SET  FORMAT  TO  main 
STORE  "  "  TO  command 

* 

♦display  the  main  menu 
READ 

* 

♦perform  selected  function 
DC  CASE 

* 

CASE  command  =  »' i” 

DC  add 

* 

CASE  command  =  HE" 

DC  delete 

* 

CASE  command  =  "E" 

ERASE 

♦prevent  dBASE  11  sign-off  msg 

SET  CONSOLE  OFF 

gDIT 

*  CASE  command  =  "H" 

*  DO  help 

*  CASE  command  =  "E" 

*  EC  print 

* 

CASE  command  =  WQ" 

DC  query 

* 

*  CASE  command  =  ”0" 

*  DC  update 

CASE  command  =  "V" 

DC  view 

* 

SNECASE 
♦loop  back 
ENDDC 
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Sign-on  Command  Module 

*  sign-on. end  6/5/84 

*  version:  1.0 

*  purpose:  to  display  the  sign-cn  message 

*  processing  narrative:  the  sign-on  msg  is  displayed,  control  is 

*  transferred  back  to  mam.cmd  when  the 

*  user  enters  a  keystroke. 

*  superordinate  modules:  main.cmd 

*  subordinate  modules:  none 

*  author:  Tom  Etheridge 

***************************************************************** 

ERASE 

7 

?  "  NAVFACENGC03" 

?  "  Contractor  Information  System” 


b  ti 
?  f1 

■j 

■j 

b  ii - 

~>  n - 


Developed  by:" 

TOM  ETHERIDGE" 

SPRING  QUARTER  1984" 

NA7A1  POSTGRADUATE  SCHOOL" 

->  Wait  10  seconds  for  system  initialization  to  complete  <- 
- >  Press  any  key  to  continue  < - " 


##*******## 


Initiation  Command  Module 

************************************************  ******  *******  ****** 


init. end 
version: 


6/5/84 

1.0 


purpose:  to  initialize  variables  and  set  the  system 
processing  narrative:  the  environment  is  set  up  id* 
*  initialing  of  the  variables  us 


vstem  environment 
p  followed  by  tr.e 
les  used  in  the 
cdata.mem  and 


*  r  J  initialing  of  the  variables  used  m  the  * 

*  add.cmd  module,  creates  cdata.mem  and  * 

*  cdis.mem.  * 

*  superordinate  modules:  main.cmd 

*  subordinate  modules:  none  # 

********************  *i*  ***************************  *  **************** 

♦run  once  to  initialize  the  variables  and  set  up  the  environment 

SET  TALK  OFF 

SET  INTENSITY  OFF 

* 

♦initialize  the  variables,  .  .  ,  ,  , 

♦currently  set  to  initialize  variables  during  each  run  of  system 
*  IF  .NOT.  FILE  {"edata.  mem") 

STOFE  "  "  TO  deleted 

STORE  "0000"  TO  menum  „  _ 

c«rnRF  "  TO  mcnanel 

storf  "  "  TO  mcnam e2 

Itoef  «  "  TO  mstpob 

STORE  "  "  TO  mcity 

STORE  "  "  TO  mstate 

STORE  "  "  TO  mzip 

STORE  "  "  TO  mphone  ... 

STORE"  "TOmpro^i 

STORE  "  "  TO  mfeel  _  mr.  • 

S^ORE  "  "  *0  mprO; ^ 

STORE  "  "  TO  mfee2  „ 

STORE"  TO  mpro  i  .i 

STORE  "  "  TO  mfee3 


STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 


♦create  cdata.mem 
SAVE  TC  edata 
♦clear  the  memory 
RELEASE  AIL 
♦ENDIF 

♦IF  .NOT.  FILE  ("cdis.mem") 
STORE  "0000"  TO  menum 
STORE  "  "  TO  mnad 

'j'rnsp  "  TO  mnee 


STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STCBE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 

STORE 


TO  mnad 
TO  mnee 
TO  mnog 
TO  mna 
TO  mnest 
TO  mnup 
TO  mnefie 
TO  mnge 
TO  mnsne 
TO  mnee 
TO  mnhy 
TO  mnsce 
TO  mnei 
TO  mnid 
TO  mnspw 
TO  mndan 
TO  mnla 
TC  mnste 
TO  mneco 
TO  mnme 
TO  mnsur 
TO  mnecn 
70  mnmne 
TO  mntre 
TO  mnge 
answer 
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♦create  cdis. mem 
SA  71  TO  cdis 
♦clear  memory 
RELEASE  ALL 
♦ENDIE 

♦set  up  the  file  environment 

SELECT  PRIMARY 

USE  cdata 

SELECT  SECONDARY 

USE  cdis 

♦return  to  mam.cmd 


Add  A  Contractor  Command  Module 


****************************'*********************************** 


*  add.cmd  6/6/84  jte  * 

*  version  1-0  * 

*  purpose:  to  permit  the  addition  of  records  to  the  file  * 

*  processing  narrative:  using  the  getcdata  and  getcdis  formats  ♦ 

*  data  is  collected  from  tne  user  and  * 

*  placed  in  the  cdata  and  cdis  files.  * 

*  superordinate  modules:  main.cmd  * 

*  subordinate  modules:  getcdata  S  getcdis  formats  * 

*  author:  Tom  Etheridge  * 


**************************************************************** 

♦set  up  environment 

SET  INTENSITY  ON 

♦set  up  the  loop 

STORE  t  TO  more 

EO  WHILE  more 

♦set  up  screen  for  cdata  entry 
SET  FCfMAT  TO  getcdata 

♦get  new  set  of  memcrv  variables  for  data  entry 

RESTORE  FROM  cdata 

SELECT  PRIMARY 

♦let  user  enter  data 

READ 

♦add  data  to  the  file 

?  "  STORING  THE  DATA _  ONE  MOMENT  PLEASE." 

APPEND  BLANK 

REPLACE  cnuml  WITH  acnum,  enamel  KITH  mcnamel 
REPLACE  cname2  WITH  mcname2 

REPIACF  stpot  KITH  mstpob,  city  KITH  mcity,  state  WITH  mstate 
REPIACF  zip  WITH  mzip 

REPLACE  phone  WITH  mphone,  projl  WITH  mproil,  feel  WITH  mfeel 

REPLACE  proj2  WITH  mproj2#  fee2  WITH  mfee2,  proj3  WITH  aproi3 

REPLACE  fee3  WITH  mfee3 

♦wait  for  the  user  response 

♦release  all  variables 

RELEASE  ALL 

*  set  screen  for  cdis  input 
SET  FORMAT  TO  getcdis 

♦get  variables  for  cdis 
RESTORE  FROM  cdis 

♦pass  the  contractor  number  to  the  cdis  file 
STORE  cnuml  TO  mcnuir2 

*  get  the  cdis  data  file 
SEIECT  SECONDARY 

♦let  the  user  input  data 
READ 

♦store  the  data  in  the  cdis  file 
APPEND  BLANK 

REPLACE  cnum2  WITH  mcnum2 

REPIACF  nad  KITH  mnad,  nee  KITH  mnee,  nog  KITH  mnog 
REPLACE  na  WITH  mna 

REPLACE  nest  WITH  mnest,  nup  KITH  mnup,  nche  KITH  mnche 
RE  PI AC  E  nge  WITH  mnge 

REPLACE  nsne  WITH  mnsne,  nee  WITH  mnee,  nhy  WITH  mnhy 
REPLACE  nsoe  WITH  mnsoe 

REPLACE  nci  WITH  mnei,  nid  KITH  mnid,  nspv  KITH  mrspw 
REPLACE  ndmn  WITH  mndmn 

REPLACE  nla  WITH  mnla,  nste  KITH  mnste,  neco  KITH  mneco 

REPLACE  nme  WITH  mnme,  nsur  WITH  mnsur,  necn  WITH  mnecn 

REPLACE  nmne  KITH  mrmne 

REPLACE  ntre  WITH  mntre,  nge  WITH  mnge 

♦are  there  more  inputs? 

IF  !  (answer)  =  "Y" 

RELEASE  ALL 
STORE  t  TO  more 
ELSE 

RELEASE  ALL 
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Delete  Command  Module 


******************** 

*  delete.cmd  6/9/84 

*  version:  1.0 

*  purpose;  to  delete 

*  processing  narrati 

* 


*  superordinate  modu 

*  subordinate  nodule 

*  author:  Tom  Etheri 
******************** 

♦clear  the  screen 
ERASE 

♦initialize  the  loca 
STORE  t  TO  more 
STORE  "  "  TO  answer  1 
STORE  "  "  TO  answer 2 
STORE  "  "  TO  answer3 
STORE  "deleted”  TO  n 
♦set  up  the  deletion 
DO  WHILE  more 


*********************************************3 

jte 

records  from  the  cdata  and  cdis  files 
ve:  local  variables  are  initialized,  the  user 
is  offered  a  look  at  the  records  in  the 
file  to  determine  the  contractor  number 
to  delete,  the  record  reguested  by  the 
user  is  displayed  to  verify  that  it  is  to 
be  deleted,  the  record  is  then  deleted, 
first  the  cdata  file  record  then  the  cdis 
file  record,  if  more  are  to  be  deleted 
then  the  loop  begins  again  else  control 
goes  tack  to  the  main  menu, 
les:  main.cmd 
s:  saycdata.fmt 
dee 

*?*******************************************: 


1  variables 


cdis  files 
ialized.  the  user 
records  in  the 
ntractcr  number 
guested  by  the 
lfy  that  it  is  to 
s  then  deleted, 
ord  then  the  cdis 
to  be  deleted 
in  else  control 
nu. 


deleted 

loop 


”  contractor  number." 

"  Do  you  need  to  see  a  listing  of  all  the 

"  contractor  numbers  and  names?  (  Y  or  N 

(ait  for  answerl 
lIT  TC  answerl 

;valuate  the  response  and  act  on  it 
r  !  (answerl )  =  "Y  ” 

STORE  "  "  TO  answerl 

*c  -play  the  contractor  numbers  and  names 
ERASE 

SELECT  PRIMARY 
?  "  #  NAME" 

DISPLAY  ALL  deleted,  cnuml,  enamel  OFF 
? 

?  "PRESS  ANY  KEY  TO  CONTINUE" 

WAIT 

(DIF 

jet  the  contractor  number 
iASE 


assiGne  dM 


assign  ed " 


ACCEPT  ”  What  is  the  contractor  number?"  TO 
♦find  the  record 
SELECT  PRIMARY 

SFT  FYACT  ON 

LOCATE  FOR  cnuml  =  !{mcnumd) 

♦check  for  eof 
IF  EOF 


menumd 
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ERASE  t  _  ...  „ 

?  "That  contractor  number  is  not  in  tne  file" 

?  "Co  you  want  to:" 

? 

?  "  1)  Try  again  or."  .  . 

ACCE?m  "  2)  Return  to  mam  menu"  TO  choice 

IE  !  (choice)  =  "1" 

LOOP 
ELSE 

★remove  the  record  and  compress  the  file 
PACK 

SELECT  SECONDARY1 
PACK 

♦return  tc  main. cmd 
RETURN 

ENDTr 

EN  DIF 

♦  display  the  record  to  see  if  it  is  the  correct  or.e 
SET  FORBAT  TO  saycdata 
READ 

♦qet  the  answers 
IF  !  (answer2)  =  "N" 


I'qet  tee  answers 
IF  !  (answer2)  =  "N" 

STORE  "  "  TO  answer2 


IOCP 

FISE 

♦mark  it  for  deletion 
REELACE  deleted  WITH  mdeleted 
DELETE 

♦get  the  edis  file 

SEIECT  SECONDARY 

LOCATE  FOR  cnum2  =  ! (menumd) 

SET  EXACT  OFF  ,  ^  , 

♦mark  the  edis  record  for  deletion 
DELETE 

♦find  if  we're  done 


?  "  Do  you  want  to  delete  more  records?  (  Y  or  N  )" 

WAIT  TO  answer3 

♦get  ansver3 

IF  I  (answer3)  =  "Y" 

♦start  over 

STORE  "  "  TC  answer3 

LOOP 

ELSE  , 

♦remove  the  marked  records  and  compress  files 

USE  caata 

PACK 

USE  edis 
PACK 

♦end  the  lccp 
STORE  f  TO  more 
ENEIF 

♦end  ansver2  if 
END  IF 

♦end  the  main  loop 
ENDDO 
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Cuery  Command  Module 

I**********#********#*:**#**********#*********#*****##***:***#*#****** 

*  query.cmd  6/11/84  jte  * 

*  version:  1.0  * 

*  purpose:  to  permit  the  dBASE  user  to  access  the  command  mode  * 

*  processing  narrative:  the  user  is  told  the  purpose  and  * 

*  requirements  of  using  the  command  mode.  * 

*  he  is  told  how  to  return  from  the  * 

*  command  mode  to  the  menu  mode.  * 

*  superordinate  modules:  main.cmd  * 

*  subordinate  modules:  none  * 

*  author:  Tom  Etheridge  * 

********************$***************#******** ********************** 
♦clear  the  screen 

ERASE 

■? 


?  "This  will  put  you  into  the  dBASE  11  command  mode  for  oueries  " 

?  "of  the  database.  You  must  know  the  command  language  to  make  " 

?  "the  queries." 

7 

♦get  the  response 

ACCEPT  "Eo  you  want  to  proceed?  (Y  or  N)  "  TO  mquery 
♦analyze  the  response  and  act  on  it 
IF  !  (mquery)  =  "Y" 

ERASE 

*p 

7 

?  "To  return  to  the  menu  mode  type  DO  MAIN  in  the  command  mode." 

?  "fress  any  key  tc  continue . good  luck!!!" 

WAIT 

♦exit  menu  mode  tc  command  mode 
ERASE 

QUIT  TO  'DBASE  B* 

ELSE 

♦return  to  main.cmd 
RETURN 
ENDIE 


View  Command  Module 


***************************************************  ******  ********** 

*  view.cmd  6/9/84  jte 

*  version:  1.0 

*  purpose:  to  browse  thru  the  data 

*  processing  narrative:  user  is  given  intro  and  offered  to  see 

*  the  numbers  and  the  names  of  the 

*  contractors,  error  checking  off  inputted 

*  numbers  is  followed  by  presenting  the 

*  records  either  in  the  indexed  order  from 

*  the  top  of  the  file  or  beginning  at  the 

*  specified  number. 

*  superordinate  modules:  main.cmd 

*  subordinate  modules:  vcdata.fmt,  vcdis. f mt 

*  author:  Tcm  Etheridge 

*****  *********  ****************************  ******  *  ********  ********* 

♦initialize  the  local  variables 

STORE  t  TO  view 

STORE  t  TO  ahead 

STORE  "  "  TO  vcommand 

♦clear  screen 

ERASE 

♦set  the  viewing  environment 

SELECT  PRIMARY 

USE  cdata  INDEX  names 

SELECT  SECONDARY 

OSE  cdis 

♦give  intro 

? 

?  "To  view  a  specific  contractor's  data  record,  you  need" 

?  "to  knew  the  contractor  number." 

?  "If  a  specific  number  is  not  used  you  will  begin  with" 

?  "the  first  record.  The  records  are  arranged  in  alphabetical" 

1  "order  by  contractor  name." 
o 

?  "You  can  also  just  browse  thru  the  records." 
h 

■j 

?  "PRESS  ANY  KEY  TO  CONTINUE" 

WAIT 

ERASE 

■9 

9 


"The  following  options  are  available  in  browse:" 


of  the  contractor" 

N) umber — Permits  you  to  locate  a  contractor" 
by  the  contractor  number" 

Q) uit — Returns  you  to  the  main  menu" 


?  "Do  you  need  to  see  a  listing  of  the  contractor  numbers" 
ACCEPT  "and  names?  (  Y  or  N  )  "TO  answerl 
♦set  loop 
DO  WHILE  ahead 
♦get  answerl 
IF  !  (answerl)  =  "Y" 

♦clear  screen  and  show  the  numbers 


ERASE 

SELECT  PRIMARY 
7  "  #  NAME” 

? 

DISPLAY  ALL  cnuml,  enamel  OFF 
*■? 

?  '• - PRESS  ANY  KEY  TO  CONTINUE - " 

WAIT 

ENDIF 

♦  get  the  user's  desires 

ACCEPT  "Do  you  want  to  see  a  specific  record?  {  Y  or  N  ) "  TC  answer 
IF  !j[answer2)  =  "Y" 

ACCEPT  "What  is  the  contractor  number?"  TO  menumb 
ELSE 

*if  no  use  the  first  record 
GOTO  TOP 

SICRE  cnuml  TO  menumb 
ENDIF 

♦  set  up  to  check  for  erroneous  data  entrv  ar.d  recovery 
SELECT  PRIMARY 

SET  EXACT  ON 
IF  !(answer2)  =  "Y" 

ICCATZ  FOR  cnuml  =  ! (menumb) 

IF  EOF 

?  "That  is  not  a  valid  number." 

ACCEPT  "Do  you  need  to  see  the  listed  numbers  again? 

(Y  or  N)  "  TO  bad 
IF  !  (bad)  =  "Y" 

STORE  *Y'  TO  answer  1 
LOOP 
ELSE 

?  "The  first  record  in  the  file  will  be  displayed." 

?  " — Press  any  key  to  continue — " 

WAIT 

GOTO  TOF 

STORE  cnuml  TO  menumb 
ENDIF 
ENDIF 
ENDIF 

♦end  the  loop 
STORE  f  TO  ahead 
ENDDO 

♦set  up  the  browsing  loop 
DO  WHILE  view 

STORE  enamel  TO  name 
♦set  up  the  screen 
SET  FORMAT  TO  vedata 
READ 

♦evaluate  the  choice 
DO  CASE 

♦check  option 
CASE  vcommand  =  "B" 

SKIP  -1 

STORE  cnuml  to  menumb 

* 

CASE  vcommand  =  "F" 

SKIP 

STORE  cnuml  to  menumb 

* 

CASE  vcommand  =  "P" 

SELECT  SECONDARY 
♦start  at  the  tot 
GOTO  TOP 

♦find  the  correct  record 
LOCATE  FOR  cnum2  =  !  (menumb) 

♦get  the  screen  readv 
SET  FOPMAT  TO  vedis  * 
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♦show  it 

READ 

WAIT 

♦restore  the  main  file 
SELECT  PRIM  ARY 

♦ 

CASE  vcommand  =  "Q" 

STORE  f  TO  view 

* 

CASE  vcommand  =  "N" 

ERASE 

♦get  the  number 

ACCEPT  "What  is  the  contractor  number?”  TO  mcnum 
♦find  it 

LOCATE  FOR  cnum  1  =  !  {mcnumb) 

♦is  it  valid 
3  1  EOF 

GOTO  TOP 

?  "That  number  is  not  valid.  Try  again.." 

?  " - Press  any  key  to  continue - " 

WAIT 
END  IF 

♦  lccp  lack 
ENECASE 

♦reset  the  variable 
STORE  "  "  TO  vcommand 
EN  E  EO 

♦restore  the  memory 
RELEASE  ALL 

♦reset  the  main  environment 
DSE  cdata 
SELECT  SECONDARY 
DSE  cdis 

♦return  to  the  main  menu 


1 1 1 


Main  Screen  Format 
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Getcdata  Screen  Format 


*********************************  ********************** ********** 
*  GETCDAIA. FMT  6/5/84  jte 

3  1,  0  SAY  - - - - 


a  ii 


3  11 
3  11 
3  11 

3  13 
3  14 
3  14 

3  15 
3  15 
3  16 
3  16 


a  18 

3  19 
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21  SAY 
0  SAY 
20  GET 
39  SAY 
47  GET 
0  SAY 
18  GET 
16  SAY 
18  GET 
0  SAY 
20  GET 
0  SAY 
7  GST 
37  SAY 
45  GET 
54  SAY 
60  GET 
10  SAY 
0  SAY 
12  GET 
0  SAY 
6  GET 
0  SAY 
12  GET 
0  SAY 
6  GET 
0  SAY 
12  GET 
0  SAY 
€  GST 


"CONTRACTOR  DATA  FILE" 
"Contractor  Number 
mcnum 
"Phone  -" 

mphone  PICTURE  •  (999)  -999-9999’ 

"Contractor  Name 

mcnamel 

ii.  ii 

mcname2 

"Street  or  P.O.Box 

mstpoS 

"City  -" 

mcity 

"State 

instate 

"Zip 

mzip 

ii — £ -  PROJECT  HISTORY  — 

"Project  1 
mproi 1 
"Fee 
mf  eel 

"Project  2 
mproj2 
"Fee  -" 
mf  ee2 

"Project  3 
mpro]3 
"Fee  -" 
mf  ee3 


Getcdis  Screen  Format 
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* 

GETCDIS.  FMT  6/5/84  jte 
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R 
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a 
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15 
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44 
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12 
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mnsne 

a 

12 

15 

SAY 

"Sanitary  Eng 

10" 

R 
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44 
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a 
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44 
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a 
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51 
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a 

19 
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19 
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<e  as  re  ra  re  (B  <9  ft?  <e  re  * e  re  re  re  rg  re  *s  re  ftj  re  <fc  re  f 0  re  (9  ft?  re  re  rs  re  ft? 


Saycdis  Screen  Format 


************************************************ ****** *********** 


*  SAYCDIS. FIT  6/5/84  jte 
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APPENDIX  B 

A-E  MANAGEMENT  INFORMATION  SYSTEM  COMPONENTS 


Below  is  a  listing  of  the  components  which  makeup  the 
A-E  Management  Information  System.  The  listing  is  broken 
into  four  categories:  databases,  files,  reports/letters 
file,  and  applications. 


Databases 


Fhases  I5II  Tracking 

Labor  Costs 

Board  Members 

Provisions 

Drawing  Numbers 

Payments 


Contract  Specialist 
Contractor  Information 
System 

Phase  III  Tracking 
Modifications  Tracking 


Applications 


Phase  ISII  Tracking 
Ccntract  Assignment 
Clearances/Approvals  I 
C er t if icates/Appr ovals 
11/111 

Evaluation  Calculator 

Signature 

DD  1057 

Progress  Payment 


Phase  III  Tracking 
Estimates 

Contractor  Information 
System 

Board  Selections 
Estimate  Evaluator 
DD  350 
DD  1413 


* 


Files 

Contracts 

Report s/letters 

Customer  Notification  Cost  Estimate 

Clearances/Approvals  Worksheet 

CBD  ,  Board  Appointments 

Pre-Selection  Board  Interview  Letter 

Report  Interview  Evaluation 

Interviewers  Instructions  Sheet 

Selection  Board  Report  G.E.  Form 

Negotiation  Board  Report  DD  350 

Contractor  Notification  DD  1057 

letter  DD  1413 

Design  Review 


Contractor  Meeting 
Checklist 

Contractor  Release 


Documents 
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Naval  Material  Command,  Washington,  D.C.,  P-4202,  Navv 
Contracting  Directives  (NCD/NPD)  ,  Sections  1-40T7T3 
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INITIAL  DISTRIBUTION  LIST 


No.  Copies 

1.  Defense  Technical  Information  Center  2 

Cameron  Station 

Alexandria,  VA  22314 

2.  Library,  Code  0142  2 

Naval  Postgraduate  School 

Mcnterey,  CA  93943 

3.  Computer  Technology  Programs,  Code  37  1 

Naval  Postgraduate  School 

Mcnterey,  CA  93943 

4.  LCDS  W.  Talutis,  Code  54TA  1 

Administrative  Sciences  Department 

Naval  Postgraduate  School 
Mcnterey,  CA  93943 

5.  Prof  N.  Lyons,  Code  54LB  1 

Administrative  Sciences  Department 

Naval  Postgraduate  School 
Mcnterey,  CA  93943 

6.  LCDS  E .  E.  Etheridge  1 

Branch  Dental  Cline 

N AVSUP ACT  Holy  Loch 
FEO  New  York  09514 

7.  Naval  Facilities  Engineering  Command  1 

Code  011  s 

200  Stovall  Street 
Alexandria,  VA  22332 

8.  Naval  Facilities  Engineering  Command  1 

Code  04 

200  Stovall  Street 
Alexandria,  VA  22332 

9.  LCDR.  J.  T.  Etheridge  2 

CBC  Code18 A  FACSC 

Port  Hueneme,  Ca.  93043 
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